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Reduced  Ship’s  crew-by  Virtual  Presence  (RSVP) 

FY99  Advanced  Technology  Demonstration  (ATD)  Final  Report 


Executive  Summary 


Program  Overview 

RSVP  was  a  proofof-concept  and  technology  demonstrator,  whose  purpose  was  to 
provide  Navy  research  and  development  risk  mitigation  for  the  DD21  program.  The  three 
year,  15  million  dollar,  BA  6.3  program  was  sponsored  by  the  Office  of  Naval  Research 
(ONR)  Ship  Hull,  Mechanical,  &  Electrical  Systems  Science  and  Technology  Division 
(Code  334).  The  high  risk,  high  payoff  ATD  was  significant  to  the  Navy  and  DOD  in 
demonstrating  an  intra-compartment,  wireless  shipboard  sensor  network.  This  will  enable 
reduced  manning,  improve  damage  control,  and  lower  total  ownership  cost  for  Navy 
ships.  RSVP  researched,  developed,  integrated  and  tested  a  functional  system  that 
incorporated  many  technologies  of  varying  levels  of  maturity.  All  program 
demonstrations  were  completely  successful,  including  a  VIP  tour  and  demonstration  of 
the  RSVP  system  aboard  CG-61  on  May  24,  2001  in  Annapolis,  MD. 

RSVP  achieved  its  final  exit  criteria  by  completing  three  full-scale  demonstrations: 
verification  and  validation  (V&V)  at  the  NSWCCD-SSES  DDG-51  Land  Based 
Engineering  Test  Site  (LBES);  an  At-Sea  trial  for  90  days  aboard  USS  MONTEREY 
(CG-61);  and  a  Damage  Control  and  Firefighting  exercise  aboard  the  Ex-USS 
SHAD  WELL  (LSD- 15),  in  coordination  with  the  Damage  Control- Automation  for 
Reduced  Manning  (DC -ARM)  program.  The  RSVP  ATD  program  came  to  a  successful 
conclusion  on  September  26,  2001,  upon  the  completion  of  the  final  demonstration 
aboard  ex-USS  SHADWELL. 


i 


NSWCCD-TR-2003/02 


System  Overview 

The  RSVP  program  pursued  three  major  areas  of  high-risk  technology  application 
development:  Advanced  sensors  in  a  high-density  configuration;  large  scale  wireless 
shipboard  intracompartment  networks;  and  data  fusion  in  support  of  shipwide  situational 
awareness.  The  RSVP  program  implemented  four  major  functional  areas  for  monitoring: 
Environment,  Structure,  Machinery,  and  Personnel.  The  primary  components  of  the 
RSVP  system  cons  ist  of : 

1 .  Autonomous  Sensor  Clusters 

These  units  monitor  the  environmental  and  structural  functional  areas.  The  cluster  is 
composed  of  three  parts;  a  sensor  board  populated  with  Commercial  Off  The  Shelf 
(COTS)  and  Micro-Electro-Mechanical  Systems  (MEMS)  sensors  and  associated 
electronics,  a  Power  Management  Module  (PMM),  and  a  radio  board.  The  PMM 
regulates  and  stores  power  from  various  power  harvesting  devices,  and  directs  power 
from  the  harvesting  sources  or  a  battery  backup.  The  Sensor  Cluster  wirelessly  transmits 
data  to  Access  Points  within  a  compartment. 

2.  Access  Points  (APs) 

Access  Points  receive  data  from  the  wireless  sensing  components  and  process  that  data  to 
provide  compartment  state.  An  AP  is  an  industrial  grade  IBM-clone  PC  running  the 
Embedded  Windows  NT  operating  system.  They  operate  off  of  ship’s  power.  These  units 
were  mounted  in  a  shipboard  compartment  to  receive  and  process  data  wirelessly  from 
RSVP  system  components,  perform  data  logging  and  maintain  a  video  loop  recorder. 
Access  Points  within  a  particular  space  exchange  data  with  each  other  so  each  can  make 
compartment  level  condition  assessments. 

3.  Personnel  Status  Monitors  (PSM) 

This  device  is  a  consists  of  two  parts:  A  Communication  Interface  Unit  (CIU)  and  an 
Integrated  Sensor  Unit  (ISU).  The  CIU  is  a  pager- like  device  that  wirelessly 
communicates  to  the  APs.  It  provides  sailor  ID  and  an  RF  signal  source  that  can  be  used 
by  the  APs  to  determine  location.  The  ISU  is  a  bio-sensor  belt  that  transmits 
physiological  data  to  the  CIU. 

4.  Machinery  Health  Monitoring  System  (HMS) 

A  wireless  HMS  system  was  implemented  on  a  Allison  K17  Ship  Service  Gas  Turbine 
Generator  (SSGTG)..  The  HMS  employs  hardware  and  software  in  a  multi-layer, 
distributed,  hierarchical  architecture,  that  monitored  portions  of  one  SSGTG.  The 
hardware  and  software  elements  included  sensors,  data  acquisition,  signal  conditioning, 
data  analysis,  archival/retrieval,  and  control,  and  two-way  RF  communication.  The 
Intelligent  Component  Health  Monitor  (ICHM)  provided  component/subsystem  level 
monitoring  while  the  System  Health  Monitor  (SHM)  combined  ICHM  information  into  a 
higher  level  system  view.  Communication  with  the  SHM,  ICHM  and  AP  was 
accomplished  via  two  independent  wireless  RF  links. 
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5.  Watchstation  and  Operator  Interface 

The  Watchstation  is  the  means  for  receiving  alarm  notification  and  for  interactive 
viewing  selected  system  data.  RSVP  had  its  own  Watchstation,  but  in  an  operational 
system  the  Watchstation  functions  would  be  performed  at  the  ship’s  general-purpose 
operator  consoles.  The  Watchstation  is  a  commercially  available  Pentium  based  computer 
running  Windows  NT,  in  a  ruggedized  rack  mount  housing. 

General  Results  and  Conclusions 

The  ATD  demonstrated  the  applicability  and  effectiveness  of  a  high  density, 
multifunctional,  wireless  monitoring  system  for  Navy  ships.  The  RSVP  program  team 
believes  this  is  an  effective  architecture  for  the  next  generation  Naval  warships  to 
achieve  minimal  manning  levels.  The  specific  components  used  in  RSVP  will  be  replaced 
by  future,  improved,  COTS  components  available  during  ship  design  and  construction. 

The  technologies  applied  by  RSVP  were  of  varying  levels  of  maturity.  The  available 
MEMS  sensors  were  effective,  as  well  as  low  power.  However,  not  all  required  sensors 
were  available  in  MEMS  or  were  low  power.  Development  of  other  low  power  sensing 
devices,  specifically  chemical  sensors,  needs  to  continue.  The  power  harvesting 
technologies  were  the  most  immature  components  of  RSVP,  and  were  not  able  to  provide 
enough  power  to  independently  sustain  a  senor  cluster.  RSVP  achieved  power  autonomy 
through  use  of  installed  batteries.  However,  die  technologies  look  promising  enough  that 
they  will  achieve  the  required  power  levels  in  the  near  future.  The  electronic  and 
processing  components  will  also  achieve  lower  required  power  levels,  helping  to  achieve 
this  goal. 

The  use  of  RF  in  the  2.4  GHz  Industrial  Scientific  and  Medical  (ISM)  band  proved 
effective,  especially  in  a  ship’s  engine  room.  There  was  also  very  little  interference  in  this 
band  during  laboratory  fire  testing  as  well.  It  is  anticipated,  however,  that  more  devices 
will  be  brought  aboard  as  new  technology  is  introduced,  and  the  spectrum  will  become 
increasingly  crowded.  Spectrum  management  aboard  ship  will  become  a  necessity. 

The  ability  to  collect  and  process  machinery  data  in  a  distributed,  wireless  hierarchical 
architecture  was  successfully  demonstrated.  Implementation  of  the  Condition-Based 
Maintenance  (CBM)  approach  and  technology  demonstrated  in  RSVP  will  support 
manning  and  total  ownership  cost  reduction  goals.  However,  to  make  truly  accurate 
condition  assessments,  predict  remaining  useful  life  and  make  operational  decisions 
based  on  this  information,  more  development  and  validation  is  required  in  the  field  of 
diagnostic  and  prognostic  software  algorithms. 

True  personnel  monitoring  can  only  be  achieved  through  a  total  ship -wide  monitoring 
system.  RSVP  was  implemented  in  the  engine  room  of  CG-61  and  in  selected 
compartments  of  ex-SHADWELL.  When  the  PSM  was  within  detection  range  of  a 
receiver,  it  was  able  to  track  a  sailor.  Both  the  PSM  and  Sensor  Clusters  will  benefit  from 
improved,  long  life  battery  technologies  as  well. 
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Much  more  development  in  data  fusion  and  advanced  reasoning  algorithms  is  required 
beyond  RSVP  to  accurately  provide  situational  awareness  in  a  minimally  manned 
shipboard  environment.  The  volume  of  data  that  a  complete  RSVP  system  would  provide 
needs  to  be  processed  to  a  level  to  that  a  remote  watchstander  can  have  accurate,  timely 
assessment,  and  can  take  appropriate  action.  The  RSVP  architecture  allows  these 
algorithms  to  be  inserted  as  they  become  available.  Development  and  demonstration  of 
the  RSVP  prototype  system  confirmed  the  critical  need  for  Human  Factors  analysis  in 
design  of  shipboard  remote  automation  systems. 
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1.0  Overview 

1.1  Introduction 

The  Reduced  Ship’s-crew  by  Virtual  Presence  (RSVP)  Advanced  Technology 
Demonstration  (ATD)  is  a  proof  of  concept  and  technology  demonstrator,  whose  purpose 
is  to  provide  Navy  sponsored  Research  and  Development  risk  mitigation  for  the  DD21 
program.  The  ATD  will  not  directly  transition  a  product  to  Navy  6.4  development  or  to 
Industry,  due  to  the  DD21  acquisition  strategy.  The  DD21  industry  teams  will  receive  the 
RSVP  developmental  end  products,  as  well  as  test,  evaluation,  and  analysis  reports.  This 
will  be  utilized  to  validate  the  RSVP  technology  application  approach  to  DD21  design, 
and  aid  the  DD21  industry  teams  in  development  and  selection  of  technologies  in  support 
of  reduced  ship  manning. 

1.2  Approach 

The  intent  of  RSVP  is  to  demonstrate  elements  of  key  high  risk  technology  areas  in  the 
implementation  of  a  Navy  shipboard  wireless  sensor  network.  RSVP  utilized  state-of-the- 
art,  developmental,  and  advanced  technologies  to  address  multiple  shipboard  monitoring 
requirements  and  demonstrate  timely,  accurate,  and  reliable  monitoring  and  assessment 
of  the  ships  state  at  the  compartment  level.  Near-real-time  actionable  information  will  be 
acquired  in  support  of  total  ship’s  situational  awareness. 

Implementation  of  the  technologies  and  approach  demonstrated  would  significantly 
reduce  manual  investigation,  improve  ship  condition  assessment  time  and  accuracy,  and 
improve  operational  readiness  and  availability.  Fully  implemented  and  deployed  in  the 
fleet,  the  demonstrated  approach  would  enable  continuous  monitoring  and  assessment  of 
ship  compartments  and  systems.  Environmental,  structural,  and  personnel  monitoring 
would  reduce  detection,  classification  and  response  time  during  a  damage  control 
evolution.  Machinery  monitoring  and  health  assessment  would  enable  rapid 
determination  of  system  configuration  and  operational  status,  early  detection  of  system 
faults  and  adverse  operating  conditions,  and  timely  and  efficient  asset  management  and 
logistic  support  coordination.  The  ability  to  remotely  obtain  accurate  and  reliable 
information  rapidly  about  the  ship,  ship  systems,  and  ship’s  personnel  would  improve 
operational  readiness  and  availability,  and  enable  reduced  manning. 
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1.3  High  Risk  Technical  Areas 

'  The  RSVP  program  has  defined  three  major  areas  of  high  risk  technology  application 
development: 

•  Advanced  Sensors  in  a  high  density  configuration 

•  Wireless  Shipboard  Intracompartment  Networks 

•  Data  Fusion  and  Advanced  Reasoning  in  support  of  Situational  Awareness. 

The  RSVP  program  has  defined  four  major  functional  areas  for  monitoring: 

•  Environment 

•  Structure 

•  Machinery 

•  Personnel. 

The  RSVP  architecture  has  several  challenging  high  risk  technology  elements.  A 
combination  of  sensors  with  widely  disparate  bandwidths  must  be  accommodated  in  a 
hybrid  network  of  wired  and  wireless  sensor  nodes.  The  sensors  must  be  nearly 
maintenance  free  so  that  they  don't  impose  a  significant  maintenance  burden.  They  must 
also  contend  on  a  priority  basis  for  a  limited  number  of  receivers.  The  receivers  must  be 
damage  tolerant,  and  be  able  to  operate  reliably  under  severe  loading  conditions  that  will 
occur  during  system  failures  or  ship  casualties. 

1.4  Problem  Statement 

The  DD21  program  has  the  goals  of  a  95  man  crew,  a  cost  of  acquisition  of  $750M  for 
5th  ship  and  follow-on,  and  O&S  costs  on  the  order  of  a  70%  reduction  from  DDG  51. 
The  drive  for  reduced  manning  as  an  O&S  cost  reducer  was  reinforced  by  the  1995 
NRAC  Study  on  ‘Life  Cycle  Cost  Reduction’  [ref  1]  and  reiterated  in  a  1996  NRAC 
‘Summer  Study  on  Damage  Control  and  Maintenance  for  Reduced  Manning’  [ref  2].  The 
study  determined  that  a  majority  of  the  total  cost  of  ownership  of  a  ship  is  operation  and 
support  costs.  Of  these  costs,  manning  is  identified  as  the  predominant  cost  driver.  As 
described  in  the  1996  NRAC  study,  reducing  manning  is  not  straightforward,  and 
“impacts  the  complex  relationship  of  manpower  requirements  for  operating,  maintaining, 
supporting,  fighting  and  saving  the  ship.  A  rational  approach  to  reduce  manning  requires 
a  systems  engineering  approach  with  in-  fleet  demonstrations  of  proof  of  principle.” 
RSVP  is  an  example  of  such  an  approach. 

1.5  Current  Architecture 

Current  Navy  sensor  systems  consist  of  a  limited  number  of  hard  wired  sensors  or  sensor 
nets,  attached  to  specific  systems  or  alarm  panels.  These  systems  have  limited  capability, 
and  are  costly  to  install  and  maintain.  Currently,  the  majority  of  shipboard  monitoring 
and  condition  assessment  is  performed  by  manual  investigation.  The  ATD  was  awarded 
based  on  the  justification  that  a  much  larger  sensor  system  than  is  currently  aboard 
today’s  ships  will  be  required  to  reduce  manning,  and  the  cost  of  installing  and 
maintaining  such  a  wired  system  would  be  prohibitive. 
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1.6  Execution 

The  RSVP  ATD  was  executed  in  three  phases:  System  Design  (FY99),  System 
Fabrication  and  Feasibility  Demonstrations  (FYOO),  and  Shipboard  Demonstrations 
(FY01).  This  structured  approach  minimized  schedule  and  cost  risk,  and  also  served  to 
maximize  early  visibility  of  technical  risk  issues. 

The  System  Design  phase  established  system  level  goals  and  associated  requirements  for 
sensors,  networks,  processors,  data  fusion,  intelligent  reasoning,  and  information 
distribution.  The  System  Design  Phase  also  defined  the  system  architecture.  The 
architecture  definition  was  supported  by  prototyping  high  risk  architectural  components, 
including  sensors,  networks,  and  algorithms  in  order  to  mitigate  system- level  risks  early 
in  the  program. 

The  System  Fabrication  and  Feasibility  Demonstration  phase  incorporated  the  design, 
implementation,  and  validation  of  component  systems,  and  culminated  in  the  integration 
and  laboratory  demonstration  of  a  prototype  RSVP  system.  A  successive- level-of- 
integration  approach  was  taken  to  ensure  critical  path  risk  items  were  addressed  and 
system  problems  were  traceable. 

The  Shipboard  Demonstration  Phase  implemented  the  fully  functional  land  based  system, 
and  consisted  of  one  land  based,  and  two  shipboard  deployments:  a  Verification  and 
Validation  (V&V)  at  the  NSWCCD-SSES  DDG-51  Land  Based  Engineering  Test  Site 
(LBES),  the  second  onboard  the  USS  MONTEREY  (CG-61)  for  a  90  day  At-Sea  trial, 
and  the  third  onboard  the  Navy's  Damage  Control  Training  and  R&D  facility,  the  ex-USS 
Shadwell. 


3 


NSWCCD-TR-2003/02 


1 .7  Exit  Criteria 

1.7.1  FY99 

1 .  RSVP  Systems  Engineering  Study 

2.  Feasibility  Demonstrations 

a.  RF  communications 

o  Conduct  at  sea  interference  susceptibility  tests.  Verify  shipboard  RF 
communications  possible  on  a  fully  operational  war  ship, 
o  Perform  RSVP  radiated  interference  tests.  Verify  RSVP  RF 
communications  doesn’t  interfere  with  shipboard  systems, 
o  Conduct  comprehensive  study  to  determine  the  effects  of  fire  in  a  RF 
communication  environment. 

b.  Sensor  Clusters 

o  Demonstrate  ultra- low  power  processing  electronics 
o  Prototype  power  management  module,  power  scavenging  interface 
o  Prototype  RF  communication  module 

c.  Data/Information  Fusion 

o  Demonstrate  capability  of  cross  correlation  of  fragmented  data  into  a 
compartment  level  database. 

3.  RSVP  Architecture  Design  and  Model  -  Define  RSVP  system  and  architecture 
reliability  requirements,  modeling  tools  to  assess  reliability  performance. 

4.  Operator  Interface  Screens  -  Define  virtual  presence.  Prototype  user  interfaces. 


1.7.2  FYOO 

1 .  Complete  Detailed  System  And  Subsystem  Designs  (Hardware  And  Software) 

2.  Fabricate  And  Test  Subsystem  Components 


1.7.3  FY01 

'  l.  LBES  Demonstration 

2.  At-Sea  Demonstration 

3.  Ex-USS  Shadwell  Demonstration 

4.  Final  Report 
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1.8  RSVP  Integrated  Product  Team  (IPT) 


Naval  Sea  Systems  Command,  Ship  Automations  and  Controls  (NA  VSEA  0533)  — 
Washington,  DC. 

NAVSEA  05J3  is  the  Navy's  lead  for  the  execution  of  this  project  and  served  as  the 
technical  interface  for  the  project  to  appropriate  governmental  and  commercial  agencies. 
The  Execution  Manager  provided  appropriate  technical  and  administrative  guidance  to 
the  execution  team. 

Naval  Surface  Warfare  Center,  Carderock  Division  —  Ships  Systems  Engineering 
Station  (NSWCCD-SSES)  -  Philadelphia,  Pa. 

NSWCCD  91 13  is  the  Technical  Manager  of  the  ATD.  NSWCCD  91 13  provides  project, 
technical  and  resource  management  to  ONR  for  ATD  execution.  NSWCCD  9534  is  the 
ATD  Technical  Director.  NSWCCD  9534  coordinated  all  ATD  technology  development, 
insertion  and  testing  on  Navy  platforms.  NSWCCD  9534  is  directly  responsible  for  the 
development  of  the  Structural  sensors  and  Power  Harvesting  technology  development 
and  insertion. 

Charles  Stark  Draper  Laboratory  ( Draper )  -  Cambridge,  Ma. 

Draper  is  the  RSVP  Lead  Systems  Integrator,  and  is  responsible  for  laboratory  integration 
and  test  of  all  component  subsystems.  Draper  developed  the  design  of  the  Environmental 
and  Structural  sensor  cluster.  Draper  developed  the  low  powered  radio  for  the  sensor 
clusters  and  APs,  as  well  as  the  RE  communications  protocol  (Drapemet)  for 
communications  between  the  sensor  clusters,  PSM  HMS  and  APs.  Draper  specified  the 
AP  units,  and  developed  the  AP  data  acquisition,  fusion  and  communications  software. 

Penn  State  Applied  Research  Laboratory  (PSU/ARL)  -  State  College,  Pa. 

PSU/ARL  is  the  leveraging  its  development  of  machinery  monitoring  technologies  and 
approach  for  implementing  a  Machinery  Health  Monitoring  System  (HMS).  This  work 
was  performed  as  part  of  the  ONR  Multi-disciplinary  University  Research  Initiative 
(MURI)  for  Integrated  Predictive  Diagnostics  (IPD)  and  the  Condition  Based 
Maintenance  (CBM)  Accelerated  Capabilities  Initiative  (ACI).  PSU/ARL  developed 
component  level  machinery  diagnostics  and  a  hierarchical  architecture  for  implementing 
distributed  processing  and  diagnostics.  The  wireless  HMS  architecture  includes 
Integrated  Component  Health  Monitors  (ICHM)  or  Intelligent  Nodes  (IN)  and  System 
Health  Monitors  (SHM)  to  assess  machinery  state,  and  to  employ  diagnostic  and 
prognostic  algorithms  to  determine  incipient  failures  and  remaining  useful  life.  RSVP  is 
providing  a  demonstration  vehicle  and  a  system  level  wireless  network  for  the  HMS 
system,  to  be  installed  on  an  Allison  501  K17  SSGTG.  PSU/ARL  constructed  ICHMs 
and  an  SHM  under  RSVP  and  developed  communications  protocols  for  the  machinery 
information  transmission  to  the  APs. 
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Sarcos  Corporation  (Sarcos)  —  Salt  Lake  City,  Ut. 

SARCOS  is  the  developer  of  the  PSM.  SARCOS  developed  its  PSM  under  a  DARPA 
program  for  the  Army  Rangers.  SARCOS  modified  its  PSM  unit  for  RSVP  to  be  a  belt 
device,  and  integrated  a  radio  compatible  with  the  RSVP  wireless  network. 

Oak  Ridge  National  Laboratory  (ORNL)  -  Oak  Ridge,  77V. 

ORNL  is  responsible  for  the  development  of  the  PMM.  ORNL  provided  a  custom 
designed  ASIC,  and  associated  electronics  for  gathering  and  storage  of  energy  from 
Power  Harvesting  sources,  as  well  as  power  regulation  to  the  sensor  clusters. 

BB&N  Technologies  (BB&N)  -Mystic,  CT. 

BB&N  is  responsible  for  developing  the  watchstation  communications  and  display 
software  (MMI).  BB&N  also  developed  the  messaging  format  for  the  HMS  system. 

Honeywell  Technology  Center  (Honeywell)  -  Minneapolis,  MN 

Honeywell  is  responsible  for  developing  the  MMI  design  specifications,  and  usability 

testing. 

Carlow  International,  Inc  (Carlow)  —  Falls  Church,  Va. 

Carlow  performed  the  Manning  Functional  Analysis  in  FY99,  and  is  currently  performing 
Manning  Analyses  and  Human  Factors  testing  to  determine  manning  reduction  metrics 
and  operator  usability  for  the  RSVP  concept. 
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2.0  Top  Level  Requirements 

2. 1  Office  of  Naval  Research  (ONR) 

ONR  directed  RSVP  to  target  manning  reductions  in  shipboard  watchstanding  to 
complement  the  ONR  sponsored  DC-ARM  program.  DC-ARM  is  developing  automation 
systems  to  reduce  manning  in  the  area  of  Damage  Control.  The  RSVP  team  chose  a 
limited  set  of  HM&E  functionality  (environment,  structure,  machinery,  personnel)  for 
automated  watchstanding.  The  first  constraint  on  the  RSVP  concept  was  chosen  by  ONR 
and  PMS  500,  for  a  wireless  shipboard  sensor  system.  The  ATD  was  awarded  based  on 
the  justification  that  a  much  larger  sensor  system  than  is  currently  aboard  today’s  ships 
will  be  required  to  reduce  manning,  and  the  cost  of  installing  and  maintaining  such  a 
wired  system  would  be  prohibitive.  The  RSVP  team  has  focused  its  efforts  on  the 
technology,  and  technology  approach  to  affordably  and  wirelessly  acquire  and  process 
large  amounts  of  data/information,  as  opposed  to  a  sensor  network  optimized  for 
automated  control. 


2.2  Integrated  Product  Process  Development  (IPPD) 

RSVP  employed  a  systems  engineering  methodology  entitled  Integrated  Product  and 
Process  Development  (IPPD).  This  methodology  and  associated  software  toolset 
provided  a  systems  engineering  approach  to  design  and  development  including  an 
emphasis  on  affordability.  Affordability  is  a  crucial  requirement  for  DD21.  IPPD  led  the 
RSVP  team  through  the  process  of  identifying  customer  requirements,  developing  and 
assessing  technology  alternatives,  determining  variabilities,  performing  risk  analyses,  and 
estimating  performance,  producibility,  and  cost. 

The  IPPD  process  identified  potential  ‘Customers’,  major  system  goals  and  scope  (based 
on  Customer  inputs),  and  performance  and  functional  requirements  (through  subject 
matter  experts  and  Customer  representatives).  Some  identified  customers  were  ONR, 
PMS  500,  PMS  400,  PMS  312,  Blue  and  Gold  Teams,  sailors,  commercial  equipment 
manufacturers.  Shipyards,  NAVSEA  Engineers,  etc.  The  IPPD  identified  customers  were 
narrowed  down  to  two  categories  to  effectively  specify  RSVP  system  requirements: 

•  Industry  -  Requirements  specified  are  for  all  the  capabilities  required  of  a  fully 
functional  RSVP  system  for  future  Naval  ships. 

•  ATD  -  Requirements  specified  for  all  of  the  capabilities  defined  within  the  scope 
of  the  ATD  and  Demonstrations. 

RSVP  then  concentrated  on  designing  a  system  that  met  the  ATD  requirements,  but  that 
would  not  preclude  the  Industry  requirements,  for  the  system  had  to  be  designed  to  be 
extensible  to  a  final  shipboard  product.  Once  the  requirements  were  gathered,  organized 
and  placed  into  customer  categories,  they  were  assigned  ranges  and  desirabilities. 
Desirability  curves  were  calculated  and  issued  weights.  These  curves  were  utilized  to 
determine  Measures  of  Effectives  (MOEs),  and  against  these  the  final  test  data  are 
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evaluated.  DD21  Blue  and  Gold  teams  have  been  actively  involved  in  RSVP.  RSVP  has 
chosen  not  to  acquire  or  use  any  competition  sensitive  information  in  its  design  and 
execution.  This  was  done  to  keep  all  of  RSVP  development  available  to  both  teams,  and 
to  avoid  any  restrictions  in  design. 

2.3  Functional  and  Performance  Requirements  Overview 

The  requirements  given  here  are  those  for  the  ATD  customer,  not  Industry. 

2.3.1  System  Functional  Requirements 

•  RSVP  will  monitor  ship  spaces  in  four  functional  areas  --  environment,  structure, 
machinery,  and  personnel  status  —  and  provide  an  operator  with  sufficient 
information  about  each  space  to  allow  it  to  be  left  unmanned  during  normal 
conditions. 

•  RSVP  will  provide  data  suitable  for  the  needs  of  graphic  interfaces. 

•  RSVP  will  provide  data  archiving. 

•  RSVP  will  provide  an  operator  with  the  health  status  of  its  own  components. 

•  RSVP  will  provide  an  operator  with  the  environmental  status  (temperature, 
humidity,  etc.)  of  a  ship  space. 

•  RSVP  will  alert  an  operator  to  an  emergency  environmental  condition  (fire,  flood, 
etc.)  in  a  ship  space. 

•  RSVP  will  provide  an  operator  with  the  recent  environmental  history  of  a  ship 
space. 

•  RSVP  will  provide  the  status  (hull  girder  stress,  hull  acceleration,  corrosivity, 
etc.)  of  a  ship's  primary  structure. 

•  RSVP  will  alert  an  operator  to  an  emergency  structural  condition  onboard  a  ship. 

•  RSVP  will  provide  an  operator  with  the  recent  history  of  ship  structure  and 
contents 

•  RSVP  will  provide  the  operational  status  of  machinery. 

•  RSVP  will  provide  the  configuration  of  machinery. 

•  RSVP  will  provide  the  health  status  of  machinery. 

•  RSVP  will  provide  an  operator  with  physiological  status  (pulse,  skin  temperature, 
etc.)  of  crew  members. 

•  RSVP  will  provide  an  operator  with  the  location  (identification  of  ship  space)  of 
crew  members. 

2.3.2  Performance  Requirements 

Performance  requirements  define  how  the  system  is  to  behave  to  succeed  in  its  intended 
mission. 

•  RSVP  will  function  during  all  operational  and  damage  conditions. 
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•  RSVP  Sensor  Clusters  will  operate  for  an  extended  time  (goal  is  five  years  from 
installation)  with  no  maintenance, 

•  RSVP  sensors  will  provide  data  based  on  time,  event,  or  query. 

•  RSVP  will  provide  video  to  an  operator. 

•  RSVP  Sensor  Clusters  will  facilitate  inexpensive  installation  by  means  of  (a) 
wireless  communication  and  (b)  a  simple  installation  procedure,  and  (c)  Original 
Equipment  Manufacturer  (OEM)  integration  with  respect  to  machinery. 

•  RSVP  will  gracefully  and  autonomously  accommodate  RSVP  components 
coming  on  line  and  going  offline  under  all  conditions. 

•  RSVP  will  provide  a  means  for  an  operator  to  modify  algorithms  in  remote 
stations  without  the  need  for  separate  operations  for  each  remote  station. 

•  RSVP  will  coexist  with  other  shipboard  electronic  equipment. 

•  RSVP  will  accommodate  additional  future  capabilities. 

•  RSVP  will  be  scalable  to  accommodate  ship  spaces. 

•  RSVP  will  be  usable  worldwide  without  the  need  for  electromagnetic  licensing. 

•  RSVP  will  adopt  open- system  architectures  and  include  definition  of  all 
interfaces. 

•  RSVP  will  alert  an  operator  that  there  is  a  fire  in  a  compartment. 

•  Goal  for  probability  of  missed  detection:  0.2%  of  actual  fires. 

•  Goal  for  time  to  detection  of  a  Class  A  fire  (due  to  combustibles  on  the  ship,  not 
an  external  event):  5  min. 

•  Goal  for  probability  of  false  alarm:  2/year  per  ship  1  (approximately  500 
compartments). 

•  RSVP  will  alert  an  operator  that  there  is  an  incipient  fire  in  a  compartment, 

•  Goal  for  alert  time  prior  to  ignition:  5  min. 

•  RSVP  will  alert  an  operator  that  there  is  a  spill  of  liquid  in  a  compartment. 

•  Goal  for  probability  of  missed  detection:  2%  of  actual  situations.  1 

•  Goal  for  time  to  detection:  30  seconds. 

•  Goal  for  probability  of  false  alarm:  2/year  per  ship  (approximately  500 
compartments). 

•  RSVP  will  alert  an  operator  that  an  environmental  limit  has  been  exceeded. 

•  Goal  for  probability  of  missed  detection:  1%  of  actual  situations. 

•  Goal  for  time  to  detection:  30  seconds. 

•  Goal  for  probability  of  false  alarm:  2/year  per  ship  (approximately  500 
compartments). 

•  Goal  for  probability  of  false  alarm:  2/year  per  ship  (approximately  500 
compartments). 

•  RSVP  will  monitor  ambient  conditions,  such  as  temperature,  humidity,  air 
pressure,  and  vacuum. 

•  RSVP  will  monitor  acceleration  on  the  hull  and  hull  contents  for  all  loading 
conditions. 

•  RSVP  will  monitor  stress  on  hull  girders  and  other  primary  structural  members 
for  all  loading  conditions. 

•  RSVP  will  monitor  the  corrosiveness  of  ship's  structural  members. 
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•  Goal  for  probability  of  missed  detection:  20%  of  actual  situations. 

•  Goal  for  probability  of  false  alarm:  0.2/year  per  ship  (approximately  500 
compartments). 

•  RSVP  will  provide  Condition-Based  Maintenance  (CBM)  capability. 

•  RSVP  will  supply  an  operator  with  machinery  health  and  operational  status 
information. 

•  Goal  for  maximum  latency  following  detection  of  change  in  status:  1  second. 

•  RSVP  will  alert  an  operator  that  there  is  an  adverse  machinery  condition 

•  Goal  for  probability  of  missed  detection:  2%  of  actual  situations. 

•  Goal  for  probability  of  false  alarm:  2/year  per  ship  (approximately  500 
compartments). 

•  RSVP  will  alert  an  operator  that  a  crew  member  is  undergoing  extreme  fatigue. 

•  RSVP  will  allow  an  operator  to  continuously  track  the  location  (to  the 
compartment  level)  of  crew  members  over  the  range  of  motion  from  stationary  to 
running. 

•  RSVP  will  allow  an  operator  to  track  crew  members'  vital  signs  with  a  maximum 
latency  of  0.5  minute. 


2.3.3  IPPD  Requirements  Specification 


Table  1.  IPPD  Requirements  Specification 


Rq 

mt 

# 

Requirement 

How  Measured 

Objecti 

ve 

Lower 

Thres. 

Upper 

Thres. 

How  tested 

1 

Fire  Detection 

Percentage  Detection 
w/in  5  mins 

100.00 

95.00 

Total  no.  of  fires 
detected/total  no.  of  fires 

2 

Fire  Detection 

HHlHi 

0.00 

1.00 

Measure  amt  false 
alarms/entire  test  period 

3 

Fire  Detection 

Time  to  Detection 
(min) 

1.00 

5.00 

Measure  time  from  point 
of  ignition 

R 

Monitor  Temperature  Set  Point 

Percentage  Detection 
w/in  30  secs 

100.00 

99.00 

Heat  up  to  above 
threshold,  determine 
time  to  detect, 
accumulate  statistics 

Monitor  Temperature  Set  Point 

Number  False  Alarms 
during  demo  period 

0.00 

1.00 

Count  false  alarms, 
divide  by  time 

W 

Monitor  Temperature  Rate  of 
Change 

Percentage  Detection 

100.00 

99.00 

Heat  up  quickly, 
measure  time  to  detect 

R 

Monitor  Temperature  Rate  of 
Change 

Measurement 
sensitivity:  Delta  T  / 
time  [deg  F/sec] 

1.00 

10.00 

8 

Monitor  Temperature  Rate  of 
Change 

Number  False  Alarms 
during  demo  period 

0.00 

1.00 

Measure  #  of  alarms,  use 
supporting  data  to 
determine  #  of  false 
alarms 

9 

Monitor  Humidity 

Measurement  Accuracy 

1.00 

5.00 

Compare  to  independent 

10 


\K 


iwtfit: 


10  [Monitor  Temp  erature 


Monitor  Pressure 


Detect  Gas  Composition  (non 
2  chemical  agent) 


13  Remote  Visual 


Detect  Noise  Event  (clang) 


Measure  Floodin 


16  [Measure  Flooding 


Monitor  Hatch  Closure 


IB  (Monitor  Hatch  Open 


Notification  of  Adverse 
19  Condition  of  Machiner 


25  Diagnose  Fault  of  Machine 


Number  False  Alarms 
during  demo  period  0.00 


Accuracy 

100.00  95.00 


Accuracy 

100.00  95.00 


%of  alarms  detected  ou 

of  number  simulated 

during  demo  period  1 00.00  95.00 


Percentage  Detection 
w/in  5  mins  100.00  95.00 


Seconds 


Percent  Accuracy  100.00  97. 


Scale:  1  -  5 


Percentage  of 

conditions  detected  out 

of  number  simulated 

during  demo  period.  100.00  90.00 


%of  alarms  detected  ou1 

of  number  simulated 

during  demo  period  1 00.00  95.00 


Number  of  Missed 

26  Diagnose  Fault  of  Machinery  Detections  during  demo  0.00 


%  of  conditions 
detected  out  of  number 
Determination  of  Condition  of  simulated  during  demo 
27  [Machinery _ period  100.00  95.00 


Compare  to  independent 
5.00  instrument 


Compare  to  independent 
.00  instrument 


Compare  to  independent 
5.00  instrument 


Perform  survey 


Compare  to  independent 
0.00  instrument 


Compare  to  independent 
0.75  instrument 


Measure  #  of  alarmss  use 
supporting  data  to 
measure  #  of  false 
1.00  alarms 


Simulated  door  closure 


Simulated  door  open 


Measure  #  of  alarms,  use 
supporting  data  to 
measure  #  of  false 
alarms 


Sim/stim  fault,  measure 
time  to  notification  at 
watchstation 


Monitor  GTG,  measure 
time  for  notification  to 
60.00  watchstation 


Number  of  correct 
operating  states  reported 
divided  by  the  number 
of  operating  states  tested 


Access  trend  data 
through  watchstation 


Translate  confidence 
level  into  measure  of 
severity  based  on  alarms 
and  alerts. 


Count  (correlate  with 
data)  them  and  divide  by 
time 


Faults  were  simulated 
using  real  data  coming 
off  the  SSGTG.  All 
faults  simulated  were 
detected  and  reported  to 
1 .00  the  watchstation 


Sim/stim 
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Determination  of  Condition  of  Number  of  Missed 


28  Machinery 


29  [Monitor  Hull  Stress 


[Detections  during  demo  | 


Measurement  Accuracy 

(psi)  _ 


Measurement  Accuracy 
30  Monitor  Hull  Acceleration  (g)  _ 


Measurement  Accuracy 
31  [Monitor  Hull  Shock  (g) 


Detect  Adverse  Physiological  Number  False  Alarms 
32  Status  during  demo  period 


Detect  Adverse  Physiological  Percentage  Detection 
33  Status  _ w/in  30  secs _ 


Monitor  Personnel  Location  |Scale:  1-5 


100.00  95.00 


5.00  I  3.00 


Development  Costs 


Time  to  Break-even  Point  |Years 


O&S  Cost  ofRSVP 


Provide  Situational  Awareness  [Scale:  1  -  5 


43  Data  Archiving 


Scale:  1  -  5 


25.00 


5.00  4.00 


5.00  1.00 


Time  to  notification 
after  detection  of  lost 
44  Provide  System  Health  Status  capability  (secs) _ 


Number  False  Alarms 

45  Provide  System  Health  Status  during  demo  period 


Wireless  IScale:  1-5 


1.00  Sim/stim _ | 

Data  gathered  by  RSVP 
System  and  analyzed  by 
100.00  independent  expert. 


Data  gathered  by  RSVP 
System  and  analyzed  by 
0.20  independent  expert. 


5.00 


Measure  #  of  alarms,  use 
supporting  data  to 
measure  #  of  false 
15.00  alarms 


Scripted  test  scenario, 
e.g.  lying  down, 
running.  Observe 


NAVMAC  will  do  study 


25.00  Not  applicable 


45.00  Not  applicable 


Comparison  of 
NAVMAC  report  and 
cost  estimates 


10.00  [Transition  Plan 


15.00 


100.00 


47  [Technology  Demonstration  [Date 


0.00 


5.00  3.00 


2001.0 
0  2001.00 


48  Harvested  Power 


|%  of  needed  power  1 100.00 1  0.00 


Demonstration  of  data 
retrieval 


Introduce  loss  of 
capability  to  system; 
measure  notification 
60.00  time 


Measure  #  of  alarms,  use 
supporting  data  to 
measure  #  of  false 
1 .00  alarms 


Completed  ATD  by 
October  2001 


Measure  output  of 
power  harvesting 
devices 


12 


NSWCCD-TR-2003/02 


2.4  Manning  Functional  Analysis  (MFAS) 

The  IPPD  requirements  were  derived,  in  part,  through  the  “RSVP  Manning  Functional 
Analysis  Study  (MFAS)”[ref  3],  This  study  performed  a  top  down  functional  analysis, 
based  on  the  DD21  Operational  Requirements  Document  (ORD).  The  DD21  ORD 
specified  the  types  of  missions  and  capabilities  that  DD21  must  perform.  From  the  top 
down  functional  analysis  were  derived  baseline  DD21  Top  Level  Operational  Scenarios, 
which  were  broken  down  into  tasks,  then  to  functions.  The  functions  then  were  evaluated 
for  their  applicability  to  RSVP  type  of  automation.  Functions  that  could  be  automated  by 
RSVP  were  identified,  and  the  types  of  information  required  to  perform  the  functions 
were  delineated.  This  required  information  was  integrated  into  the  RSVP  IPPD 
requirements  generation  process. 


2.4.1  MFAS  Information  Requirements 

The  following  are  a  subset  of  RSVP  information  requirements  that  were  identified  in  the 
MFAS,  Appendix  A  -  Functional  Analysis  and  Requirements.  These  requirements  were 
fed  into  the  RSVP  IPPD  Requirements  generation  process. 


Engineering/Damage  Control  Tasks  Information  Requirements 


1.  Account  for  personnel 

2.  Communications 

3.  BDA  assessment 

4.  Investigation  -  Fire 

5.  Investigation  -  Flooding 

6.  Evaluate  desmoking  system 


Personnel  Location/Condition 
Voice  Communications 
Compartment  View 
Fire  location,  size,  source 
Flood  location,  rate,  source 
Ventilation  flow  rate 


Machinery  Monitoring  Tasks 
Turbine/shaft  output  acceptable 
Verify  oil  pressure 
Verify  fuel  pumps,  heaters,  flow 
Verify  SSGTG  response 
Verify  SSGTG  operation 
Verify  turbine,  generator,  lube  oil 


Information  Requirements 

Shaft  speed  &  bearing  temp.,  lube  oil  flow 

Shaft  speed  &  bearing  temp,  lube  oil  flow 

Fuel  transfer  tank  level  &  valve  align. 

Electrical  dist.  fuel,  lube  oil 

Turbine  speed,  electrical  output 

Fuel  service  tank  level  &  lube  oil  supply 
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2.4.2  DD21  Top  Level  Scenario  Summary 

The  following  is  an  excerpt  of  a  DD21  top-level  operational  scenario  developed  in  the 
MFAS: 

Mission  (Based  on  DD21  ORD): 

2.  Three  DD  21  platforms  as  part  of  a  theater  force  supporting  an  amphibious  raid 
conforming  to  USMC  Operational  Maneuver  from  the  Sea  (OMFTS)  in  a  two  day 
mission. 

a.  DD  21  #1  performs  land  attack  segments 

b.  DD  2 1  #2  and  #3  perform  MIW  engagements 

3.  Engagements: 

a.  Mine  field  neutralization. 

b.  Support  of  a  land  attack  on  an  Iranian  chemical  plant. 

4.  Engagement  Objective: 

a.  Neutralize  shore  batteries  and  provide  fire  support  to  an  airborne 
amphibious  mission  to  retrieve  chemical  weapons  located  approximately 
30  miles  inland  Criteria  for  Engagement  Success. 

b.  Successful  timely  removal  of  shore  batteries  and  SAM  sites. 

c.  Successful  fire  support  of  airborne  amphibious  operation. 

d.  Successful  ship  self  defense  from  surface  craft,  coastal  missiles,  and 
hostile  aircraft. 

e.  Successful  identification  of  mines  and  support  of  Mine  Countermeasures 
(MCMs)  removing  the  mines. 

f.  No  losses  due  to  friendly  fire 

g.  Avoid  friendly  aircraft  in  the  area. 

h.  Respond  to  simultaneous  air  and  surface  threats. 

i.  Conduct  simultaneous  traverse  through  a  mine  field. 

2.4.3  RSVP  Applicable  Scenario  Engagement  Events 

The  following  are  engagement  events,  derived  from  the  DD21  Top  Level  Scenario,  where 
RSVP  can  be  applied: 

1 .  Response  to  a  mine  hit  on  DD  21  #2. 

2.  DD  21  #3  conducting  corrective  maintenance  -  propulsion  system. 

3.  Response  to  an  Anti- Ship  Cruise  Missile  (ASCM)  hit  on  DD  21  #1 . 

2.4.4  RSVP  Demonstration  Scenarios 

RSVP  has  developed  four  major  demonstration  scenarios  to  support  the  top  level  scenario 
and  the  RSVP  applicable  engagement  events: 

Scenario  1 .  Machinery  Maintenance 

Scenario  2.  Steaming  in  Heavy  Seas  Scenario 

Scenario  3.  Missile  Hit  above  the  Waterline  Scenario 

Scenario  4.  Mine  Encounter  with  Hull  Breach  and  Flooding  Scenario 
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3.0  Systems  Engineering 

3.1  System  Design  Constraints 

The  wireless  sensor  system  approach  is  not  a  forgone  conclusion  for  optimal  technology 
application  to  reduce  shipboard  manning.  RSVP  had  to  be  validated  against  many  critical 
and  competing  requirements  and  constraints.  Each  requirement  and  constraint  impacted 
all  others,  and  required  many  engineering  tradeoffs. 

3.1.1  Capability 

Estimates  are  that  at  least  an  order  of  magnitude  more  sensors  will  be  required  then  are 
on  ships  today  to  provide  the  necessary  coverage  for  reduced  manning.  There  will  also  be 
required  many  more  sensor  types  than  currently  are  on  ships,  or  even  available 
commercially.  The  system  requires  a  large  amount  of  processing  power  that  does  not 
currently  exist  shipboard  for  data  fusion  of  sensor  data.  The  system  also  needs  to  provide 
assessment,  situational  awareness  and  advanced  reasoning  processes. 

3.1.2  Cost 


The  system  cannot  cost  more  to  purchase  and  operate  than  the  cost  of  the  men  removed. 
The  cost  of  purchase  and  installation  also  has  to  be  held  to  a  certain  percentage  of  total 
ship  acquisition  cost.  The  Navy  also  realizes  that  it  can  no  longer  afford  to  create  a 
military-only  technology  solution.  There  has  to  be  a  private  industry  demand  for  these 
technologies  to  that  they  can  be  bought  at  prices  that  are  a  result  of  manufacturing 
economies  of  scale. 

3.1.3  Reliability 

The  system  has  to  provide  required  functionality  without  major  maintenance  for  all 
shipboard  operational  environments.  The  system  cannot  ‘fail’  at  the  same  rate  as  current 
shipboard  sensing  systems.  This  would  require  putting  crew  back  onboard  just  to 
maintain  the  system,  and  therefore  create  a  costly  maintenance  burden.  Estimates  are  for 
the  system  to  require  little  or  no  maintenance  for  3  to  5  years,  the  typical  ship  overhaul 
cycle. 

3.1.4  Survivability 

The  system  has  to  function  in  severe  combat  and  damage  environments.  It  has  to  be 
dynamically  reconfigurable.  Situational  awareness  of  the  entire  ship  should  be 
maintained  with  a  graceful  degradation  of  capability. 
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3.2  Models 


3.2.1  Cost  Model 

At  the  beginning  of  the  RSVP  program  (Winter  1999),  an  estimate  was  made  of  the  cost 
of  sensors  plus  people  to  instrument  a  DDG-51  in  that  year.  This  was  compared  against 
an  estimate  of  sensors  plus  people  to  instrument  a  DD-21  in  the  year  2008.  These 
estimates  and  the  detail  behind  them  were  included  in  the  RSVP  Systems  Engineering 
Study  [ref  4],  and  are  summarized  in  Table  2.  At  the  end  of  the  program  (Summer  2001), 
two  similar  exercises  were  performed  to  estimate  the  cost  of  sensors  and  people  to 
instrument  a  DD-21.  The  first  2001  estimate  was  for  the  current  year,  when  the  cost  of  a 
Sensor  Cluster  is  estimated  to  be  $2000;  the  second  2001  estimate  is  for  an  unspecified 
future  year  when  the  projected  cost  of  a  Sensor  Cluster  had  declined  to  $500.  This 
information  is  also  summarized  in  Table  2Table  2.  In  all  cases  the  system  cost  is  for 
equipment  and  people  for  one  ship  with  a  lifetime  of  40  years. 

Table  2  Evolving  RSVP  Cost  Estimates 

Platform  Sensor 

Time  of  Time  Cluster  Sailor  System 


Estimate  Platform  Frame  _ Cost _ MM/M _ Cost* 


Start  of 
Program, 
Winter  1999 

Wired 

DDG-51 

1999 

$3000 

34 

$128  M 

Wireless 

DD-21 

2008 

$120 

0 

$54  M 

End  of 
Program, 
Summer 
2001 

Wireless 

DD-21 

2001 

$2000 

0.5 

$89  M 

Wireless 

DD-21 

TBD 

$500 

0.5 

$57  M 

*  Cost  of  equipment  and  people  for  one  ship  for  40  years 


Table  3  summarizes  the  differences  in  assumptions  between  the  1999  and  2001  exercises. 
There  are  large  differences  in  the  cost  of  individual  Sensor  Clusters  and  Access  Points 
and  the  number  of  these  units  per  ship  space.  These  differences  are  based  on  RSVP 
program  experience.  There  is  also  a  difference  in  the  number  of  man-hours  associated 
with  repairs.  The  hope  at  the  outset  was  that  reliability  and  redundancy  would  be 
sufficient  to  ensure  that  no  maintenance  on  RSVP  would  have  to  be  performed.  Based  on 
availability  modeling  performed  by  the  RSVP  program,  this  goal  is  impractical,  and  a 
small  number  of  man-hours  for  repairs  is  now  being  assumed.  While  it  would  be  possible 
to  provide  a  zero- maintenance  system,  such  a  system  would  require  Sensor  Clusters  and 
Access  Points  that  are  much  more  reliable,  which  would  command  a  much  higher  price. 
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Table  3  Cost  Model  Assumptions 


Attribute 


1999  estimate 
for  DD-21  if 
done  in  2008 


2001  estimate 
for  DD-21  if 
done  in  2001 


Comments 


Machinery  spaces 
per  ship 

N/A 

20 

RF  characteristics 
different  from  testing 

Total  spaces  per 
ship 

500 

506 

Based  on  number  of 
spaces  on  a  DDG-51. 
Treat  each  MER  as  4 
smaller  spaces;  RF 
propagation  between 
smaller  spaces  poorer 
than  tested 

None 

9/20 

Indicated  by  Availability 
model 

Sensor  Clusters  per 
machinery  space 

50 

20  (includes 
10  ICHMs) 

Higher  number 
impractical  due  to  SC 
size  &  limits  on  locations 

Access  Points  per 
machinery  space 

4  (assumes 
SHM 

functionality 
built  into  AP) 

4  (assumes 
SHM 

functionality 
built  into  AP) 

Sensor  Clusters  per 
non-machinery 
space 

50 

10 

Higher  number 
impractical  due  to  SC 
size  &  limits  on  locations 

Access  Points  per 
non-machinery 
space 

4 

2 

Sensor  Cluster  cost 

$120 

$2000 

Individual  transducers 
cost  approx  $100  each  in 
2001 

Access  Point  cost 

$3000 

$8000 

Approximate  cost  of  an 
industrial  PC  and  camera 

3.2.2  Availability 

RSVP  was  not  given  specific  availability  goals.  However,  to  assess  the  practicality  of  the 
technical  approach,  and  to  come  to  a  balance  between  reliability  and  maintenance  costs, 
an  availability  model  was  dewloped.  An  availability  target  was  computed  from  DD-21 
availability  requirements,  and  from  assumptions  about  the  number  of  systems  that  must 
work  for  DD-21  to  be  considered  available  and  the  number  of  compartments  that  contain 
those  systems.  A  Monte  Carlo  model  was  developed,  and  its  results  validated  by 
comparing  them  to  those  produced  by  a  rudimentary  Markov  model.  Availability  was 
contrasted  against  cost.  The  results  of  this  effort  are  documented  in  the  Availability 
Modeling  Report  and  its  addenda  [ref  5,6,7],  It  should  be  noted  that  the  “repair  all  on 
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threshold”  maintenance  strategy  yields  the  highest  availability  per  unit  cost.  That  is, 
failed  equipment  is  not  repaired  unless  a  compartment  has  experienced  enough  failures 
that  it  is  no  longer  considered  available.  At  that  point,  a  technician  is  dispatched  to  the 
compartment,  and  all  failed  components  are  repaired. 

Table  4  gives  the  availability  model  input  parameters  that  were  varied. 

Table  4  Availability  Model  Input  Parameters  Varied 


Aspect 

Parameter  Baseline 

Parameter  Variations 

Number  of  Environment 
and  Structure  Sensor 
Clusters 

15  of  each  type 

10  of  each  type;  25  of 
each  type 

Reliability  of  Access 
Points,  Video,  Sensor 
Cluster  core  (see  Note  1), 
and  Personal  Status 
Monitors 

50,000  hr 

25,000  hr 

Mean  time  to  repair  for 
Access  Points,  Video,  and 
Sensor  Clusters 

Access  Points:  2  hr 

Video,  Sensor  Clusters:  1 
hr 

Access  Points:  4  hr 

Video,  Sensor  Clusters:  2 
hr 

Repair  strategy 

“Repair  all  on  threshold” 
(see  Note  2) 

“Repair  on  failure;” 
“repair  on  threshold” 
(see  Note  2) 

Number  of  Sensor 
Clusters  needed  to 
accomplish  data  fusion 

5 

10;  12 

Note  1: 

Sensor  Cluster  core  consists  of  radio,  processor,  and  power  management  module.  Failure  of  any 
part  of  core  constitutes  failure  of  entire  Sensor  Cluster.  Sensors  were  considered  to  be  separate 
elements.  Failure  of  a  sensor  does  not  prevent  the  rest  of  the  Sensor  Cluster  from  being  used. 

Note  2: 

Repair  on  failure:  A  technician  is  sent  to  the  compartment  to  perform  a  repair  whenever  a 
component  fails. 

Repair  on  threshold :  A  technician  is  sent  to  the  compartment  to  perform  repairs  whenever  enough 
failures  have  occurred  to  make  the  compartment  unavailable.  All  failed  components  that 
contributed  to  the  unavailability  are  repaired. 

Repair  all  on  threshold :  A  technician  is  sent  to  the  compartment  to  perform  repairs  whenever 
enough  failures  have  occurred  to  make  the  compartment  unavailable.  All  failed  components  are 
repaired. 
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3.3  Requirements  Implementation 

Table  5  identifies  the  functional  requirements  specified  in  4.1.1  of  the  Systems 
Engineering  Study,  and  notes  which  requirements  were  implemented.  It  should  be  noted 
that  these  requirements  were  on  a  deployed  system  that  might  be  developed  from  RSVP 
principles,  not  the  RSVP  system  itself,  so  complete  compliance  would  not  be  expected. 

Table  5  RSVP  Functional  Requirements  vs.  Implementation 

Functional  Requirement 
Described  in  Systems 


Engineering  Study  _ Implementation _ Comments 


RSVP  will  monitor  ship  spaces  in 
four  functional  areas — 
environment,  structure, 
machinery,  and  personnel 
status — and  provide  an  operator 
with  sufficient  information  about 
each  space  to  allow  it  to  be  left 
unmanned  during  normal 
conditions. 

No  manning  was  required  to 
support  environment,  structure  or 
machinery  sensing. 

This  was  the  intention  of  the 
program 

RSVP  will  provide  data  suitable 
for  the  needs  of  graphic 
interfaces. 

Implemented 

Graphical  interface  implemented 
to  show  capability 

RSVP  will  provide  an  operator 
with  the  health  status  of  its  own 
components. 

Health  information  was  provided 
for  the  machinery  health 
monitoring  system  only,  which 
consisted  of  sensor  and 
communication  health  as  well  as 
temperature  of  the  Intelligent 
Nodes 

Health  status  of  RSVP 
components  was  determined  by 
running  lower  lever  programs, 
but  not  reported  to  the 
watchstation 

RSVP  will  provide  an  operator 
with  the  environmental  status 
(temperature,  humidity,  etc.)  of  a 
ship  space. 

Implemented 

RSVP  will  alert  an  operator  to  an 
emergency  environmental 
condition  (fire,  flood,  etc.)  in  a 
ship  space. 

Implemented 

Both  fire  and  flooding  conditions 
detected 

RSVP  will  provide  an  operator 
with  the  recent  environmental 
history  of  a  ship  space. 

Implemented 

RSVP  will  provide  the  status 
(hull  girder  stress,  hull 
acceleration,  corrosivity,  etc.)  of 
a  ship's  primary  structure. 

Implemented,  except  for 
corrosivity 

RSVP  will  alert  an  operator  to  an 
emergency  structural  condition 
onboard  a  ship. 

Not  Implemented 

Sensor  data  was  acquired  by  the 
system.  Watchstation  alerts  and 
alarms  were  not  implemented  due 
to  time  and  budget  constraints. 
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RSVP  will  provide  an  operator 
with  the  recent  history  of  ship 
structure  and  contents. 

Implemented 

RSVP  will  provide  the  . 
operational  status  of  machinery. 

Implemented 

RSVP  will  provide  the 
configuration  of  machinery. 

Partially  Implemented 

Application  of  additional  sensors/ 
acquisition  of  existing  sensor  data 
constrained  by  limitations  in 
altering  SSGTG  accessing  signal 
form  machinery  control  LAN 

RSVP  will  provide  the  health 
status  of  machinery. 

Implemented 

RSVP  will  provide  an  operator 
with  physiological  status  (pulse, 
skin  temperature,  etc.)  of 
crewmembers. 

Implemented 

RSVP  will  provide  an  operator 
with  the  location  (identification 
of  ship  space)  of  crewmembers. 

Implemented 

Table  6  enumerates  the  overall  RSVP  technical  approach  features  listed  in  the  Systems 
Engineering  Study,  section  4.6. 1.1.  The  table  also  indicates  the  actual  implementation  of 
each  feature  by  the  RSVP  program. 
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Table  6  RSVP  Technical  Approach  vs  Implementation  (1  of  2) 


Technical  Approach 
Described  in  Systems 

Engineering  Study _ Feature  Implemented _ Comments 


Access  Points  hard- wired  to 
ship’s  power  and  a  data 
network 

Implemented 

Sensor  Clusters  powered  by 
energy  scavenging,  backed 
up  by  battery 

Energy  scavenging 
demonstrated,  but  Sensor 
Clusters  powered  by  battery 

Energy  harvesting 
technology  immature; 
prototype  devices  bulky  and 
require  customized 
installation  procedures 

Sensor  Clusters  use  wireless 
RF  link  for  communication 
with  Access  Point 

Implemented 

Sensor  Clusters  have 
downlink  capability 

Implemented 

Machinery  SHM  and 

ICHMs  powered  by  power 
to  machine  being  monitored 

Used  Ships  Power 

Ships  power  used  for  HMS. 
Power  not  taken  from  GTG 
skid  -  approach  minimized 
interface  issues  with 
approval  for  installation  of 
HMS  on  GTG 

SHM  communicates  with 

AP 

Implemented 

ICHMs  communicate  with 
SHM  via  wireless  link 

Implemented 

HBi^H 

Implemented 

Personnel  Status  Monitors 
powered  by  battery 

Implemented 

PSMs  communicate  via 
wireless  link 

Implemented 

PSMs  have  downlink 
capability 

Implemented 

Table  7  selectively  enumerates  additional  technical  approach  features  from  the  Systems 
Engineering  Study.  The  table  also  indicates  the  actual  implementation  of  each  feature  by 
the  RSVP  program. 
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Table  7  RSVP  Technical  Approach  vs.  Implementation  (2  of  2) 


Technical  Approach 
Described  in  Systems 

Engineering  Study _ Feature  Implemented _ Comments 


Video  at  each  Access  Point 

Video  and  audio  at  each 
Access  Point 

Save  cost  of  implementing 
analysis  of  audio 
information 

Radio- frequency 
communication  via 
continuous-wave 
transmissions  in  2.4  GHz 
industrial,  scientific, 
medical  band 

As  described,  except  for 
communication  between  AP 
and  SHM,  IEEE802.il  2.4 
GHz  spread  spectrum 
commercial  radios  used 

Random  access  (Aloha 
without  acknowledge)  used 
for  RF  medium  access 

Sensor  clusters  employ 
time-division  multiplexing 

Concerns  about  loss  of  data 
caused  by  packets  colliding 
when  all  Sensor  Clusters 
transmitting  at  high  rate  due 
to  damage  situation 

Machinery  employs  IEEE 
802.11 

Transmission  of  large  data 
block  between  AP  and 

SHM  would  take  tens  of 
minutes  at  57.6  kb/s 

Data  rate  =  200  kb/s 

Data  rate  =  57.6  kb/s 

Data  encryption 

Not  implemented 

Not  necessary  for  proof  of 
concept 

Sensor  Clusters  monitor 
temperature,  smoke, 
humidity,  carbon  monoxide, 
closure  switch,  pressure, 
noise,  strain,  acceleration, 
humidity,  sodium  ion 

-  Sodium  ion  omitted 

-  Oxygen  and  differential 
pressure  added 

-  Both  photoelectric  and 
ionization  smoke  detectors 
included 

Carbon  dioxide  sensor 
would  have  been  useful  for 
fire  detection,  but  no  low- 
power  sensor  available 

Machinery  equipment 
monitors  vibration, 
temperature,  generator  3 
phase  current  and  voltage, 
exciter  current  and  voltage 

Implemented 

Final  sensor  suite  limited 
based  on  requirement  not  to 
alter  SSGTG  or  tap  existing 
signals  (control  system). 

Full  sensor  suite  not 
required  for  demonstration 
proof  of  concept. 

Personnel  monitoring  of 
heart  beat,  skin  temperature, 
ambient  temperature, 
acceleration 

Implemented 

Data  fusion  to  employ 

NDDS  to  realize  publish/ 
subscribe 

Implemented 
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3.4  Risk  Mitigation 

3.4.1  RF  Testing 

3.4.1.1  RF  Radiated/Susceptibility  Tests 

A  critical  part  of  the  RSVP  system  is  the  wireless  communication  network.  It  must 
operate  reliably  in  a  less  than  ideal  environment  inside  of  ship  spaces  where  there  is  a  lot 
of  machinery  and  other  obstacles  disturbing  radio  wave  propagation.  In  addition,  there 
are  many  electromagnetic  noise  and  interference  sources  that  could  degrade  its  operation. 

The  purpose  of  the  shipboard  EMI/EMC  testing  was  to  determine  a  typical 
electromagnetic  environment  in  three  different  ship  spaces  in  order  to  find  potential 
interference  and  noise  problems  for  the  RSVP  Communication  System.  These  tests  were 
made  aboard  the  USS  Normandy  (CG-60),  a  Ticonderoga  Class  Aegis  Cruiser,  They 
were  conducted  during  the  period  of  April  6-8, 1999  off  Norfolk,  Virginia  under 
conditions  where  most  shipboard  systems  were  operating. 

Since  the  operating  frequency  band  for  RSVP  is  planned  to  be  the  2.4  GHz  ISM  band, 
this  was  of  the  most  interest.  Also,  since  the  present  RSVP  receiver  design  uses  IFs  of 
approximately  100  MHz  and  10.7  MHz,  the  bands  surrounding  these  frequencies  were 
also  of  critical  interest. 

The  EMI/EMC  measurements  were  made  over  several  bands  spanning  the  range  10  KHz 
to  3  GHz  us  ing  a  set  of  antennas  and  a  spectrum  analyzer.  The  entire  band  was  included 
In  order  to  have  a  point  of  reference  should  interference  problems  develop  in  the  sensors 
or  in  data  and  signal  processing  electronics. 

The  “Shipboard  EMI/EMC  Test  Report  ”  [ref  8]  describes  the  test  methodology,  test 
environment,  pertinent  measurement  data  and  the  conclusions  drawn  from  the  at-sea 
testing.  The  cooperation  and  assistance  of  the  officers  and  enlisted  crew  of  the  USS 
Normandy  is  gratefully  acknowledged  and  sincerely  appreciated. 

The  EMI/EMC  Shipboard  Tests  on  the  USS  Normandy  produced 

encouraging  results.  Interfering  signals  in  the  desired  2.4  GHz  ISM  band  were 

found  to  be  non-existent  in  the  ship  spaces  measured.  The  propagation  tests  showed  that 

communication  at  the  desired  data  rate  of  200  kbit/sec  can  be  achieved  under  near  “worst 

case”  conditions  providing  the  receiver’s  noise  figure  is  sufficiently  low.  Under  actual 

operating  conditions  with  several  access  points,  SNR’s  should  be  significantly  higher  on 

average. 
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3.4.1.2  Breadboard  Radio  Testing 

Radio  tests  were  conducted  aboard  the  USS  Normandy  (CG-60)  at  Naval  Station  Norfolk 
during  the  week  of  02  January  2000.  The  purpose  of  the  tests  was  to  verify  the 
performance  of  the  RSVP  breadboard  radios  in  a  realistic  environment  and  to  further 
determine  the  radio  channel  characteristics  in  Main  Engine  Room  2  and  Auxiliary 
Machinery  Room  1.  These  spaces  present  a  severe  multipath  propagation  environment 
due  to  the  presence  of  many  large  pieces  of  machinery  that  reflect  and  scatter  radio 
waves. 

It  is  in  fact  this  severe  multipath  environment  that  actually  enhances  the  overall 
performance  of  the  RSVP  radio  system.  By  providing  a  large  number  of  reflected  and 
scattered  signals  of  random  phase  and  amplitude,  the  shadowing  and  blockage  effects  of 
the  machinery  are  minimized.  Reliable  links  may  be  established  over  paths  which  provide 
absolutely  no  direct  line- of- sight.  This  means  that  the  number  of  Access  Points  required 
to  communicate  with  sensor  clusters  may  be  kept  low,  perhaps  only  two  or  three  even  for 
large  spaces  like  the  Main  Engine  Room.  The  data  taken  actually  show  that  a  single, 
carefully  placed  Access  Point  Radio  could  reliably  communicate  with  most  any  point 
within  the  room.  System  availability  requirements  would  dictate  more  than  one,  so  a 
quantity  of  two  or  three  is  probably  a  more  realistic  minimum. 

The  prototype  of  the  low  power  RSVP  radio  is  shown  in  Figure  1 . 

RSVP  Radio  Breadboard 


1st  IF  Filter 
(100.6MHZ) 


Digital 

Interface 


Down  Converter 


IF  Demodulator 


Synthesizer 


Antenna  Connector 


T/R 

Switches 


Synthesizer 
Data  Driver 


Figure  1  RSVP  Radio  Breadboard 
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3.4.1.3  RF/Fire  Testing 

The  Naval  Postgraduate  School  was  tasked  to  conduct  a  study  on  the  effects  of  fire  on  RF 
communications.  The  objective  was  to  quantify  experimentally  the  effects  of  ship 
compartment  fuel  fires  (diesel  and  heptane)  and  the  water  mist  fire  extinguishing  system 
on  the  propagation  of  RF  signals  in  the  2.4  GHz  to  2.485  GHz  ISM  frequency  range 
using  the  ex-USS  Shadwell  fire  research  facilities  operated  by  the  Naval  Research  Lab. 
The  test  was  conducted  in  May  of  1999.  RF  Attenuation  in  the  ISM  band  was  treasured 
using  a  pair  of  narrowband,  narrow  beam  (high  gain/directivity)  linearly  polarized 
antennas.  The  effects  of  fire  and  water  mist  fire- extinguishing  system  were  also  measured 
using  a  pair  of  non-directional  patch  antennas  which  are  more  representative  of  typical 
communications  antennas  for  indoor  use.  The  antennas  were  positioned  in  the 
“simulated”  machine  space  such  that  the  “fire  source”  was  approximately  halfway 
between  the  transmitting  and  the  receiving  antenna.  The  measurements  indicated  that  the 
effect  of  a  ship  compartment  fire  and  the  water  mist  fire  extinguishing  can  be  modeled  as 
rapid,  frequency  selective  fading  with  relatively  small  average  value  of  signal  loss  (the 
probability  of  signal  gain  is  slightly  smaller  than  die  probability  of  signal  loss).  Complete 
details  can  be  found  in  the  “Effects  of  Fire  and  Fire  Extinguishing  on  Wireless 
Communications  in  the  2.4  GHZ  ISM  Band”  report  [ref  9]. 


Figure  2  Frequency -Averaged  Attenuation  for  Directional  Antennas 
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Figure  3  Frequency -Averaged  Attenuation  for  Patch  Antennas 


The  effects  of  fire  and  water  mist  fire  extinguishing  were  found  to  be  profoundly 
different  for  directional  (high  gain)  and  non- directional  (low  gain)  antennas 
The  difference  is  caused  by  the  prevalence  of  a  single,  direct  path  for  the  directional 
antennas  as  opposed  to  the  multipath  propagation  for  the  non-directional  antennas 
The  attenuation  per  unit  length  for  directional  antennas  exhibits  relatively  small 
variations  with  time  and  frequency.  The  attenuation  due  to  water  mist  extinguishing  was 
substantially  larger  than  the  attenuation  due  to  the  fire  itself. 

The  average  for  attenuation  for  Directional  Antennas  (includes  fire  and  water  mist 
extinguishing)  in  the  entire  2.4  GHz  ISM  band  was  0.69  dB/m  for  vertical,  and  0.54 
dB/m  for  horizontal,  with  almost  100%  of  the  values  in  the  0  to  2  dB/m  range. 

The  loss  of  only  2db  was  encouraging,  indicating  that  the  RSVP  RF  transmission  would 
be  able  to  overcome  this  attenuation.  The  patch  antenna  produced  similar  results. 

3.4.1.4  Demonstrate  Ultra -Low  Power  Processing  Electronics 

To  better  understand  the  high-risk  areas  of  the  ultra  low  power  sensor  module,  Draper 
prototyped  the  environmental  sensor  module.  Included  in  the  prototype  were  the  power 
management  algorithms  necessary  to  achieve  the  lower  power  attribute.  Sensor  interface 
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Figure  4  Breadboard  Environmental  Sensor  Cluster 


Further  details  on  the  low  power  architecture  are  covered  in  Section  4.1.2,  RSVP 
Hardware. 
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3.4.2  Data/Information  Fusion 

3.4.2.1  Information  Architecture 

The  manner  in  which  RSVP  information  is  distributed  throughout  given  compartment  is 
through  a  publish/subscribe  paradigm.  The  basic  methodology  is  people  or  processes 
subscribe  to  RSVP  information,  such  as  fire  alarms.  The  compartment’s  APs  are  the 
publisher  of  fire  alarm  messages.  The  APs  hold  on  the  fire  alarm  subscription  until  it 
cancelled  by  the  subscriber.  No  further  information  needs  to  be  sent,  once  an  AP 
determines  an  alarm  the  AP  automatically  knows  who  he  needs  to  send  it  to  by  virtue  of 
the  subscription.  This  messaging  approach  minimizes  LAN  traffic.  Figure  5  presents  this 
approach  graphically. 

Information  Infrastructure 


*  Access  Points  share  data 
with  each  other  to  acquire 
complete  compartment  data 

•  Publish/Subscribe 
Paradigm 


Remote 

Watchstation 


Figure  5  Information  Infrastructure 
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3.4.2.2  Data  Fusion 

Understanding  the  different  types  of  data  fusion  that  are  needed  in  a  system  like  RSVP  is 
very  difficult,  RSVP  is  intended  to  feed  data/information  to  other  systems  and  processes 
and  some  of  the  systems  have  not  been  developed  yet.  Figure  6  is  a  block  diagram  that 
describes  the  different  levels  of  data  fusion  within  the  RSVP  architecture.  More  detailed 
discussion  concerning  the  data  fusion  can  be  found  in  the  RSVP  Systems  Engineering 
Study  and  other  related  RSVP  documents. 
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Figure  6  RSVP  Data  Fusion 
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3.4.3  Power  Harvesting 

The  RSVP  program  has  investigated  three  different  power-harvesting  methods  for  sensor 
cluster  battery  augmentation. 

•  Light-to-Electric  (Photovoltaic) 

•  Thermo- to- Electric 

•  Vibration-to-Electric. 

Various  risk  mitigation  efforts  were  performed  for  these  technology  areas. 

3.4.3.1  Light  Energy  Survey 

The  Oak  Ridge  National  Laboratory  (ORNL)  performed  an  ambient  light  survey  aboard 
the  USS  Supply  (AOE  6),  June  30,  1999.  The  purpose  of  the  survey  was  to  examine  the 
internal  light  levels  aboard  a  commissioned  US  Navy  ship.  The  intended  use  is  to  convert 
the  stray  internal  light  to  usable  power  to  run  various  RSVP  sensors.  It  was  thought  that 
the  sensor  array  that  would  be  used  would  draw  about  1  mW  power  on  average  from 
various  power  sources  within  the  sensor  cluster. 

The  study  concluded  that  there  is  not  a  sufficient  light  level  in  the  measured 
compartments  to  supply  all  the  power  required  by  a  sensor  cluster.  If  the  sensor  cluster  is 
to  be  placed  in  some  of  the  darker  compartments,  Photovoltaics  are  not  a  realistic  option 
for  more  than  5-10%  of  the  present  power  requirements.  For  complete  test  procedures 
and  results,  please  refer  to  the  “Photovoltaic  Measurements  for  RSVP  Report”  [ref  10]. 


30 


NSWCCD-TR-2003/02 


3.4.3.2  Vibration  Energy  Survey 

A  Vibration  and  Temperature  survey  was  performed  aboard  the  USS  MONTEREY  (CG- 
61)  16-17  October  2000  (Figure  7  and  Figure  8)  This  survey  was  performed  to  determine 
ambient  thermal  and  vibration  levels  within  MER#2.  This  data  was  then  used  to  guide  the 
power  harvesting  manufacturers  to  optimize  their  devices.  The  complete  test  results  can 
be  found  in  the  “RSVP  Power  Harvesting  Survey  Report”  [ref  11]. 


Figure  7  Average  Vibration  Levels  in  MER#1  aboard  CG-61 
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4.0  Architecture 

4.1  Environmental  and  Structural  Sensor  Cluster 


Figure  9  Environmental/Structural  Cluster  Final  Implementation 


4.1.1  Overview 

This  section  describes  the  major  electrical  and  functional  characteristics  of  the  RSVP 
Environmental  Sensor  Cluster  and  Structural  Sensor  Cluster  (ESC  and  SSC)  -  Figure  9. 
The  Environmental  Sensor  Cluster  is  designed  to  monitor  a  set  of  parameters  to 
determine  whether  a  fire  or  flooding  condition  exists  in  a  ship  compartment.  Included  are 
redundant  temperature  sensors,  both  photoelectric  and  ionization  smoke  sensors,  and 
sensors  that  monitor  carbon  monoxide,  oxygen,  and  humidity  levels.  A  differential 
pressure  sensor  can  measure  flooding  using  an  external  probe.  An  external  input  is  also 
available  for  a  hatch-position  indicator.  The  Structural  Sensor  Cluster  provides  external 
interfaces  for  two  navigation  accelerometers,  a  shock  accelerometer,  and  two  Sarcos 
strain  sensors.  The  Structural  Sensor  Cluster  samples  these  sensors  periodically,  and 
adjusts  its  sample  rate  as  warranted  by  sea  conditions.  The  shock  sensor  is  only 
monitored  in  General  Quarters  mode  to  conserve  power. 

Data  from  both  the  Environmental  and  Structural  Sensor  Clusters  are  periodically 
transmitted  to  an  Access  Point  (AP)  in  the  compartment,  which  combines  that  data  with 
data  received  from  other  clusters  and  forwards  it  on  to  a  monitoring  station.  Alert 
conditions  are  also  sent  to  the  Access  Point  whenever  a  sensor  reading  exceeds  a 
predetermined  threshold.  The  Access  Point  can  change  thresholds  and  sample  rates  to 
select  an  optimum  tradeoff  between  data  granularity  and  power  consumption. 

The  Environmental  and  the  Structural  Sensor  Clusters  share  the  same  circuit  board 
design.  Portions  of  the  circuit  board  are  populated  differently,  a  function  of  which  cluster 
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is  being  assembled.  A  completed  cluster  assembly  includes  the  environmental  or 
structural  circuit  board,  a  power  module  containing  a  battery  pack  and  regulators,  and  a 
radio  module  that  provides  the  RF  link  to  the  Access  Point, 

4.1.2  RSVP  Hardware 

4.1.2.1  Microcontroller 

Both  Sensor  Clusters  use  a  Motorola  68HC705B 1 6  Microcontroller,  which  was  selected 
for  its  low  power  consumption,  low  cost,  and  suitability  for  the  application.  The  HC05 
family  encompasses  many  versions,  each  targeted  at  a  specific  range  of  applications.  The 
68HC705B16  includes  internal  RAM  for  data  storage,  EPROM  for  the  program,  and  non¬ 
volatile  memory  (EEPROM)  for  serial  number,  calibration  coefficients,  and  alterable 
operational  parameters.  It  includes  an  8-bit  A/D  converter,  which  provides  better  than  1% 
resolution  for  analog  sensor  measurements.  It  also  includes  an  asynchronous  serial 
interface,  which  is  used  to  pass  data  over  the  RF  link.  This  same  serial  interface  is 
multiplexed  through  external  logic  to  communicate  via  a  standard  RS232  link  to  a  laptop 
computer  for  test  and  calibration. 

The  major  limitation  of  the  HC05  family  is  that  it  is  a  simple  8-bit  microcontroller,  and 
contains  only  a  single  accumulator  and  an  8-bit  index  register.  However,  the  8-bit 
restriction  only  is  a  factor  for  the  stress  measurements  and  the  environmental  sensor 
digital  filters,  which  are  processed  as  16-bit  quantities.  Another  shortcoming  of  the  HC05 
family  is  that  its  onboard  watchdog  timer  is  only  functional  with  the  processor  clock 
running.  To  achieve  lowest  power,  the  microcontroller  must  be  put  into  the  sleep  mode 
whenever  possible,  wherein  the  processor  clock  is  stopped.  Because  a  robust  system 
should  have  a  watchdog  timer,  this  function  was  duplicated  external  to  the 
microcontroller  for  the  sensor  clusters. 

4.1. 2.1.1  Timebase 

The  time  base  used  for  RSVP  is  based  on  a  32-kHz  quartz  crystal.  Its  accuracy  can  be 
trimmed  to  better  than  .001%.  Assuming  synchronization  with  an  Access  Point  every  100 
seconds,  timing  accuracy  should  be  better  than  one  millisecond.  For  minimum  power 
consumption,  RSVP  uses  a  micropower  oscillator  for  the  32-kHz  crystal,  which  drives  a 
standard  CMOS  Motorola  timer  chip.  The  sensor  cluster  normally  runs  with  a  1.00- 
second  “heartbeat.”  The  timer  can  be  adjusted  in  powers  of  two,  from  0.25  second  to  32 
seconds.  The  longest  time  interval  is  used  during  extended  sleep  modes  to  minimize 
power  consumption.  The  timer  produces  an  interrupt  to  the  processor  at  the  specified 
time.  During  normal  operation,  this  initiates  a  sensor  scan,  and  perhaps  a  data 
transmission. 

4.1.2.1.2  Sensors 

The  on-board  sensors  include  temperature,  smoke  (photoelectric  and  ionization),  carbon 
monoxide,  oxygen,  humidity,  and  ambient  pressure.  The  Environmental  Sensor  Cluster 
also  can  monitor  flooding  and  hatch  closure  through  external  connections. 
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4.1.2.1.2.1  Temperature 

Temperature  is  a  physical  quality  that  can  vary  throughout  a  compartment,  particularly  if 
that  compartment  contains  machinery.  Monitoring  temperature  rise  will  give  insight  into 
the  spread  of  fire.  Early  fire  detection  requires  accurate  monitoring  of  changes  in  the 
habitation  temperature  range.  Tracking  fire  movement  requires  the  ability  to  read  very 
high  temperatures.  Multiple  temperature  sensors  provide  optimum  performance  in  the 
selected  ranges,  and  provide  redundancy  in  measuring  this  critical  parameter. 

An  active  semiconductor  temperature  sensor  with  gain  and  bias  adjustments  provides 
high  accuracy  and  resolution  sufficient  to  be  used  for  environmental  controls  (better  than 
1  degree  F).  To  maximize  resolution  in  this  range,  the  habitation  sensors  will  not  track 
temperatures  in  excess  of  100  degrees  Centigrade. 

A  wide-range  thermistor  is  included  for  catastrophe  monitoring.  Glass- encapsulated 
thermistors  rated  for  operation  to  300  degrees  Centigrade  are  available  from  multiple 
sources.  Because  it  is  likely  the  sensor  cluster  itself  will  cease  operation  before  that 
temperature  is  reached,  the  wide-range  thermistor  is  mounted  just  inside  one  of  the 
louvers  to  sample  the  air  before  the  electronics  is  subjected  to  the  extreme  temperature. 
Accuracy  of  the  wide-temperature  range  thermistor  has  been  compromised  to  provide  the 
wide  range,  but  will  be  sufficient  to  track  movement  of  a  fire.  Even  thought  an 
Environmental  Sensor  Cluster  may  only  provide  high  temperature  readings  for  a  short 
time  before  it  is  destroyed,  these  readings  may  be  of  critical  importance  in  an  emergency. 
The  original  plan  was  to  cross- correlate  readings  from  the  active  linear  temperature 
sensor,  the  wide-range  thermistor,  and  a  second  thermistor  optimized  for  operation  in  the 
habitation  range.  However,  since  thermistors  are  small,  consume  low  power,  and  require 
little  interface  circuitry,  three  thermistors  optimized  for  the  habitation  range  are  used  to 
provide  redundancy  for  the  fire  detection  algorithm.  While  these  are  not  as  accurate  as 
the  active  linear  sensor  over  the  entire  range,  their  accuracy  is  sufficient  for  fire  detection. 
A  cross-correlation  algorithm  averages  the  three  readings  if  they  are  similar,  and  does 
intelligent  selection  of  the  closest  two,  or  mid- value  select  when  the  readings  do  not 
agree. 

RSVP  uses  a  100-kfil  glass-bead  thermistor  produced  by  SeMitec.  Three  of  these  devices 
are  configured  to  provide  1 -degree-Centigrade  accuracy  over  the  habitation  range  of —20 
C  to  +100  C.  The  same  thermistor  in  a  slightly  different  configuration  provides  the  0  C  to 
+250  C  range  needed  for  the  wide-range  temperature  sensor.  While  it  could  be  calibrated 
for  10-degree  accuracy  over  the  full  range,  the  single-point  calibration  used  for  RSVP 
should  yield  accuracy  better  than  25  C.  The  performance  was  not  confirmed  through  high 
temperature  testing.  The  wide-range  thermistor  is  located  just  inside  a  louver  to  maximize 
the  amount  of  time  it  will  monitor  an  extreme  temperature  before  the  electronics  becomes 
stressed  to  the  point  of  failure. 

This  set  of  heterogeneous  temperature  sensors  provides  the  optimum  performance.  The 
active  semiconductor  temperature  sensor  provides  best  accuracy  throughout  the 
habitation  range.  However,  because  it  is  mounted  to  the  circuit  board,  it  is  slower  than  the 
thermistors  to  respond  to  changes.  The  triplex  thermistor  set  provides  a  fast  and  reliable 
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readout  for  the  fire  detection  algorithm.  The  wide-range  thermistor  adds  the  ability  to 
track  the  movement  of  a  hot  fire  that  is  beyond  the  range  of  the  habitation  sensors. 

A  multi-criteria  fire  detection  algorithm  was  developed  to  cross- correlate  readings  from 
multiple  sensors  to  provide  a  reliable  means  of  detecting  fire.  It  is  possible  to  match 
temperature,  smoke,  and  other  parameters  before  issuing  a  fire  alert.  Using  different 
sensors  with  different  scale  factors  and  operating  characteristics  should  help  eliminate 
false  warnings  that  could  be  produced  by  common  faults,  such  as  a  low  supply  voltage, 
A/D  converter  errors,  or  processing  errors.  The  Access  Point  has  full  control  in 
establishing  the  thresholds  and  determining  which  sensors  will  be  included  in  the  multi¬ 
criteria  fire  detection  algorithm. 

4.1.2.1.2.2  Smoke  Detectors 

While  standard  alarm  integrated  circuits  exist  for  both  photoelectric  and  ionization  smoke 
detectors,  the  chambers  that  actually  perform  the  sensing  are  not  readily  available.  The 
RSVP  Environmental  Sensor  Clusters  use  photoelectric  and  ionization  smoke-detector 
chambers  obtained  from  First  Alert  consumer  fire  alarms.  Since  the  circuitry  in  consumer 
alarms  is  designed  to  operate  from  a  9- volt  battery,  it  was  not  possible  to  use  the 
available  alarm  integrated  circuits  for  RSVP.  These  functions  were  duplicated  with 
custom  micropower  analog  circuitry,  and  use  digital  processing  in  the  microcontroller. 
The  photoelectric  smoke  detector  works  by  measuring  reflection  of  an  infrared  light 
source  off  smoke  particles.  To  achieve  sufficient  operating  life  from  a  9- volt  battery,  a 
typical  home  smoke  alarm  only  pulses  the  infrared  light  source  every  30  to  45  seconds. 
RSVP  uses  a  higher  sampling  rate  to  achieve  quicker  response  time.  To  keep  energy 
consumption  within  an  acceptable  range,  the  pulse  current  is  reduced  to  half  the  current 
typical  in  a  home  smoke  detector,  and  the  pulse  width  is  also  halved.  The  resulting  signal 
at  the  photodetector  is  just  above  the  noise  floor,  but  an  exponential  digital  filter 
effectively  eliminates  the  noise.  The  photoelectric  smoke  detector  is  only  sampled  on 
those  cycles  when  the  data  will  be  transmitted,  as  defined  by  the  background  transmit  rate 
or  the  rapid  transmit  rate.  When  a  fire  alert  is  set,  the  photoelectric  smoke  detector  is 
sampled  once  a  second  for  maximum  performance.  The  output  of  the  infrared  LED  drive 
circuit  is  monitored  to  confirm  the  current  drive  remains  in  the  correct  range.  This 
provides  a  means  of  confirming  the  infrared  source  is  operating  correctly  when  no  smoke 
is'  being  detected. 

The  ionization  smoke  detector  measures  the  relative  resistance  of  room  air  compared  with 
air  enclosed  in  a  sealed  chamber.  Ionization  reduces  the  effective  resistance  of  the  room 
air.  This  measurement  requires  a  very  high  input- impedance  amplifier  due  to  the  very  low 
currents  involved,  and  required  careful  layout  to  minimize  leakage  currents  external  to 
the  sensing  chamber.  This  circuit  is  powered  continuously  because  the  very  low  currents 
prevent  it  from  stabilizing  quickly  enough  for  accurate  readings  if  power  were  cycled. 

4.1.2. 1.2.3  Carbon  Monoxide  Level 

Most  carbon  monoxide  sensors  are  power- hungry  devices.  For  that  reason,  many  of  the 
consumer  carbon  monoxide  detectors  have  been  designed  to  plug  into  a  120- VAC  outlet. 
The  carbon  monoxide  sensor  selected  for  RSVP  is  a  unit  developed  by  CRL  that  is 
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appropriate  for  battery  operation,  and  quotes  a  5-year  lifetime.  Monox,  Limited,  a  British 
firm,  markets  this  unit.  A  typical  sensing  circuit  is  described  in  application  data  from 
Monox.  This  circuit  was  modified  to  operate  from  a  3-volt  supply  using  micropower 
amplifiers.  A  monitor  was  provided  on  the  control  loop  to  confirm  correct  operation  of 
the  carbon  monoxide  cell  if  excessive  carbon  monoxide  levels  are  indicated.  Because  it 
can  take  the  carbon  monoxide  sensor  many  minutes  after  power  is  applied  before  it 
stabilizes  with  an  accurate  reading,  the  carbon  monoxide  sensor  control  loop  is  powered 
whenever  power  to  the  cluster  is  switched  on.  The  microcontroller  monitors  the  rate  of 
change  after  turn-on,  and  outputs  a  default  value  until  it  has  stabilized. 

4.1.2.1.2.4  Oxygen  Level 

The  oxygen  sensor  selected  for  RSVP  is  essentially  a  battery  whose  output  voltage  varies 
linearly  with  the  percentage  of  oxygen  in  the  atmosphere.  One  sensor  has  an  operating 
life  between  one  and  two  years.  Provision  has  been  made  to  employ  two  oxygen  sensors, 
the  second  of  which  would  be  switched  on  when  the  first  reaches  its  end  of  life.  While  the 
“cold  sparing”  was  demonstrated  in  the  prototype,  the  second  cell  location  was  not 
populated  in  the  production  units  because  of  the  short  operational  test  for  RSVP.  Under 
normal  operation,  a  low  resistance  is  placed  across  the  oxygen  sensor,  and  the  millivolt 
drop  across  that  resistor  is  a  measure  of  the  percentage  oxygen  in  the  atmosphere.  To 
maximize  the  operational  life  of  the  oxygen  sensor  cell,  the  load  is  only  switched  on 
when  the  Environmental  Sensor  Cluster  has  established  communication  with  an  Access 
Point.  The  load  is  removed  whenever  communication  loss  forces  the  Environmental 
Sensor  Cluster  into  its  sleep  mode. 

As  with  a  normal  flashlight  battery,  the  oxygen  sensor  cell  takes  minutes  to  stabilize  at  a 
constant  voltage  output  after  it  is  switched  on.  Like  with  the  carbon  monoxide  sensor,  the 
microcontroller  monitors  the  rate  of  change  of  the  oxygen  sensor  after  it  is  turned  on,  and 
outputs  a  default  value  until  the  cell  has  stabilized. 

4.1.2.1.2.5  Humidity 

Data  indicates  humidity  can  be  a  useful  indicator  when  trying  to  determine  the  type  of 
fire.  The  humidity  sensor  acts  as  a  variable  capacitor,  and  is  used  in  a  micropower 
oscillator  circuit.  Changes  in  humidity  vary  the  capacitance,  and  the  corresponding 
oscillator  frequency.  The  oscillator  is  only  switched  during  a  sensor  scan  to  conserve 
power.  After  the  oscillator  has  stabilized,  the  period  that  it  takes  the  oscillator  to  produce 
a  fixed  number  of  cycles  is  measured  by  the  microcontroller.  This  period  varies  linearly 
with  relative  humidity.  Because  the  nominal  value  of  the  humidity  sensor  can  vary 
significantly,  the  number  of  cycles  that  are  measured  can  be  adjusted  during  calibration  to 
provide  the  required  resolution. 

4.1.2.1.2.6  Ambient  Pressure 

A  semiconductor  ambient  pressure  sensor  was  included  for  RSVP  to  provide  an 
indication  of  overpressure  in  a  sealed  compartment.  The  circuitry  was  designed  to 
produce  1%  accuracy  and  resolution,  but  we  found  that  many  of  the  sensors  installed  on 
the  production  Environmental  Clusters  did  not  meet  their  specifications.  It  is  uncertain 
whether  this  was  a  lot  problem  with  the  sensors  themselves,  or  whether  it  was  due  to 
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contamination  getting  into  the  sensing  port  during  assembly.  Because  the  pressure  sensor 
is  not  an  essential  element  of  the  Environmental  Cluster,  the  degraded  performance  was 
accepted.  A  different  pressure  sensor  from  another  manufacturer  was  used  for  the 
flooding  measurement,  and  worked  as  expected  on  all  units.  That  unit  was  physically 
different,  and  had  input  ports  that  protected  it  from  contamination. 

4.1. 2.1. 2.7  Flooding 

Two  types  of  flooding  sensors  were  considered  for  RSVP.  The  first  was  a  tank  level 
sensor  whose  resistance  varies  with  liquid  level.  An  analog  input  was  incorporated  into 
the  prototype  Environmental  Sensor  Cluster  board  to  read  such  a  sensor.  Later  it  was 
decided  to  use  a  differential  pressure  sensor  to  read  flooding  level,  and  this  sensor  was 
added  to  the  production  units.  A  plastic  tube  is  brought  out  to  connect  to  a  sensor  probe 
on  those  Environmental  Clusters  that  are  used  to  measure  flooding  level.  The  length  of 
the  plastic  tube  can  affect  the  reading  because  the  air  in  the  tube  compresses  slightly  as 
the  water  level  rises.  It  is  possible  to  obtain  high  accuracy  by  calibrating  the  flooding 
sensor  with  the  actual  sensing  element.  The  gain  is  adjusted  as  required  to  accommodate 
the  compression  of  the  air  in  the  tube. 

4.1.2.1.2.8  Hatch  Position 

Hatch  position  can  be  read  with  either  switches  or  an  analog  indicator.  The  analog  input 
originally  included  for  the  flooding  sensor  is  now  used  for  the  hatch  position  input. 
Assuming  an  analog  sensor,  this  input  has  two  thresholds  to  indicate  when  a  door  is  fully 
open  or  fully  closed.  The  electrical  excitation  signal  to  the  sensor  is  only  switched  on 
when  the  readout  is  made  to  conserve  energy. 

4.1.2.1.2.9  Sensor  Power  Consumption 

One  major  factor  considered  during  the  design  of  the  RSVP  electronics  was  power 
consumption.  If  all  sensors  were  left  on  continuously  they  would  be  a  major  drain  on 
energy  resources.  Only  those  sensors  that  do  not  stabilize  quickly,  such  as  the  carbon 
monoxide  sensor,  are  left  on  continuously.  The  control  loops  for  these  sensors  use 
micropower  operational  amplifiers  to  minimize  power  consumption.  All  other  sensors  are 
only  powered  once  a  second  for  the  short  sensor  scan  interval.  The  photoelectric  smoke 
detector  is  not  normally  sampled  on  eveiy  sensor  scan  because  of  its  high-energy 
demands.  It  is  only  sampled  prior  to  a  scheduled  background  transmission  unless  it  is 
tracking  a  smoke  or  fire  event.  The  sensor  scan  is  only  performed  when  the 
Environmental  Cluster  is  actively  communicating  with  an  Access  Point  to  further 
conserve  energy. 
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4.1.3  Operational  Characteristics 

4.1.3.1  Monitor  Mode  (Unlocked)  Versus  Acquisition  Mode  (Locked) 

When  the  68HC705B16  microcontroller  is  initially  programmed,  the  EEPROM  is 
normally  unlocked  and  erased.  When  unlocked,  its  entire  contents  can  be  altered.  The 
microcontroller  has  the  ability  to  lock  all  but  the  first  32  bytes  of  EEPROM.  All 
calibration  constants  and  system  operational  constants  that  are  not  expected  to  be 
changed  are  stored  in  the  upper  portion  of  EEPROM  that  is  locked  when  the  sensor 
cluster  is  placed  into  the  acquisition  mode.  Operatio  nal  constants,  such  as  alert  thresholds 
and  sample  rates,  are  stored  in  the  lower  32  bytes  of  EEPROM  so  the  Access  Point  can 
modify  them  via  the  RF  link  while  the  sensor  cluster  is  in  operation.  The  state  of  the 
EEPROM  determines  whether  the  sensor  cluster  proceeds  into  the  acquisition  mode  after 
power  up,  or  whether  it  will  remain  in  the  configuration  monitor. 

When  the  microcontroller  is  initially  programmed  and  the  EEPROM  is  erased,  the  32-bit 
serial  number  should  be  all  Is  (FFFFFFFF  in  hexadecimal).  Whenever  the 
microcontroller  powers  up,  it  checks  the  status  of  the  serial  number  stored  in  EEPROM. 
If  the  serial  number  is  all  Is,  the  firmware  will  initialize  the  entire  EEPROM  to  the 
default  values  stored  in  ROM.  The  EEPROM  can  be  forced  back  to  the  default  values 
after  the  sensor  cluster  has  been  in  service  by  resetting  the  serial  number  to  FFFFFFFF 
via  the  configuration  monitor.  (Note  that  this  will  overwrite  any  calibration  data  stored  in 
EEPROM,  and  that  data  should  be  preserved  first  if  the  cluster  was  calibrated.)  The 
default  setting  for  the  serial  number  is  52535650  in  hexadecimal,  which  represents 
“RSVP”  in  ASCII.  The  serial  number  being  set  to  “RSVP”  indicates  to  the  firmware  that 
the  sensor  cluster  EEPROM  has  been  initialized,  but  the  sensors  have  not  been  calibrated. 
As  part  of  the  calibration  process,  the  actual  device  serial  number  is  written  into  the 
EEPROM. 

The  monitor  mode  is  entered  following  power  up  whenever  the  EEPROM  is  unlocked.  In 
the  monitor  mode,  the  sensor  cluster  will  communicate  with  a  laptop  or  other  PC  via  its 
RS232  link  at  19.2K  baud.  With  the  RS232  connection  in  place,  the  monitor  mode  can  be 
optionally  entered  when  the  EEPROM  is  locked  by  typing  the  “space”  character  within 
two  seconds  after  power  is  switched  on,  followed  by  the  string  “RSVP”  within  10 
seconds.  If  the  first  character  is  not  the  “space”  character,  or  if  anything  other  than 
“RSVP”  is  subsequently  received,  the  sensor  cluster  will  immediately  proceed  into  the 
acquisition  mode,  and  will  try  to  establish  communication  with  an  Access  Point.  While  in 
the  configuration  monitor,  the  sensor  cluster  will  respond  to  a  list  of  commands  that  are 
useful  for  test  and  calibration  of  the  sensors.  Included  are  commands  to  lock  and  unlock 
the  EEPROM.  All  commands  for  both  Environmental  and  Structural  Sensor  Clusters  are 
defined  elsewhere  in  this  document. 
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4.1 ,3.2  Acquisition  Mode  Network  Management 

RSVP  communication  uses  synchronous  transmission  in  assigned  timeslots.  The  Access 
Point  (AP)  transmits  a  frame  marker  at  the  beginning  of  each  one -second  minor  frame. 
The  Sensor  Clusters  (SC)  synchronize  to  the  frame  marker,  and  establish  communication 
through  a  request  and  grant  process. 

When  an  SC  powers  up  in  a  compartment,  it  must  establish  communication  with  an 
Access  Point.  It  first  listens  on  the  PSM  channel  for  transmissions  from  Access  Points, 
and  records  the  signal  strength  and  channel  number  for  any  AP  found.  After  listening  and 
recording  for  one  second,  the  SC  sorts  the  list  of  channels  by  signal  strength.  If  no  APs 
were  heard,  the  SC  repeats  the  listen-and-reeord  operation  on  the  alternate  PSM  channel. 
If  no  AP  Is  heard  on  either  PSM  channel,  the  SC  automatically  powers  down  and  goes 
into  a  micropower  sleep  mode  for  a  preset  interval.  The  sleep  interval  is  held  in 
EEPROM,  and  can  be  programmed  via  the  RS232  link. 

Assuming  at  least  one  AP  is  heard,  the  SC  switches  to  the  channel  of  the  strongest  AP 
and  listens  for  its  periodic  header.  The  periodic  AP  header  is  not  only  the  timing 
reference  for  its  channel,  but  it  also  contains  a  list  of  all  other  AP  channels  active  in  that 
compartment.  After  synchronizing  with  the  header,  the  SC  will  transmit  a  slot  request 
message,  including  its  ID  code.  The  SC  will  receive  a  slot  assignment  in  the  next  AP 
header  if  it  is  accepted.  The  slot  assignment  is  used  by  that  SC  for  all  further 
communication.  The  slot  defines  a  time  period  relative  to  the  start  of  the  frame.  If  no  slot 
assignment  is  received  from  that  AP,  the  SC  switches  to  the  channel  of  the  next  strongest 
AP  in  the  table,  and  repeats  the  process  until  the  last  AP  in  the  table  is  tried.  (Grounds  for 
an  AP  to  refuse  an  SC  include  a  loading  imbalance  -  too  many  SCs  already  on  this  AP 
and  not  enough  on  another  AP  in  the  compartment  -  and  the  AP  thinking  the  SC  is  in  a 
different  compartment.)  If  still  no  slot  assignment  is  received,  the  SC  will  go  through  the 
table  once  more,  but  this  time  issuing  an  emergency  request.  A  “busy”  AP  Is  required  to 
accept  a  SC  issuing  an  emergency  request,  if  at  all  possible. 

When  an  SC  receives  a  slot  assignment  from  an  AP,  it  resets  its  internal  timebase  to  wake 
up  just  prior  to  that  timeslot,  and  powers  down.  Exactly  one  second  later  the  SC  powers 
up,  scans  its  sensors,  and  transmits  its  data.  At  its  subsequent  timeslots,  the  SC  only 
transmits  data  if  a  threshold  is  exceeded,  or  if  it  is  a  regularly  scheduled  background 
transmission.  The  background  and  alert  transmit  rates  can  be  adjusted  by  the  AP.  The  SC 
will  resynchronize  with  the  AP  once  during  each  100-second  major  frame,  when  the 
frame  count  matches  its  assigned  slot  number.  To  conserve  power,  this  is  the  only  time 
the  SC  receiver  is  powered  to  receive  data  transmitted  by  the  AP.  The  SC  transmits  its 
diagnostic  data  following  each  resynchronization. 

While  it  is  not  necessary  for  an  SC  to  transmit  data  when  nothing  has  changed,  each 
cluster  transmits  at  a  low  background  rate  so  the  AP  can  maintain  a  health  status  of  each 
SC.  If  an  SC  has  missed  several  expected  background  transmissions,  it  is  likely  to  have 
lost  communication.  The  cause  may  be  as  innocuous  as  a  weak  battery  or  a  blocked  RF 
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path,  or  it  could  signal  something  serious  is  happening  in  the  compartment.  In  any  case, 
loss  of  communication  is  worthy  of  investigation. 

If  an  AP  goes  down,  all  SCs  communicating  with  that  AP  must  migrate  to  other  APs.  As 
with  the  initial  search,  the  SCs  will  switch  to  other  APs  whose  channel  numbers  are  in 
their  frequency  table,  beginning  with  the  strongest.  If  the  table  contains  no  other  APs,  or 
communication  cannot  be  established  with  any  of  the  APs  in  the  table,  then  an  SC  will 
repeat  the  initial  search  on  the  PSM  channel.  When  an  AP  goes  down,  each  SC  will  lose 
communication  during  re-sync  relative  to  its  slot  assignment.  As  a  result,  all  SCs  migrate 
to  other  APs  in  an  orderly  manner.  Slot  requests  are  offset  in  the  communication  window 
as  a  function  of  the  SC  ID  number.  This  will  reduce  the  chance  of  SCs  stepping  on  each 
other’s  transmission  in  the  unlikely  event  that  more  than  one  SC  requests  a  slot 
assignment  in  the  same  frame. 

Occasionally  the  AP  may  have  to  modify  system  parameters  in  the  SC.  The  AP  sending 
the  corresponding  message  to  that  SC  during  its  synchronizing  frame  header 
accomplishes  this.  After  correcting  its  timer,  the  SC  will  accept  data  contained  in  the 
message,  and  update  its  EEPROM  as  required.  Because  the  SC  may  not  synchronize  on 
its  first  attempt,  the  AP  may  have  to  repeat  the  programming  message  for  several  frames 
after  the  earliest  expected  resynchronization  frame.  Receipt  of  the  diagnostic  message 
from  that  SC  will  confirm  it  has  resynchronized  and  accepted  the  downlink.  Modified 
parameters  can  also  be  automatically  echoed  back  to  the  AP  if  this  option  is  selected  in 
the  configuration  flags  stored  in  EEPROM. 

4.1.3.3  Sensor  Data  Processing 

All  environmental  sensors  except  the  photoelectric  smoke  detector  are  sampled  once  a 
second  after  communication  has  been  established  with  an  AP.  The  photoelectric  smoke 
detector  is  a  power- hungry  device  because  it  requires  pulsing  an  infrared  LED  to  measure 
reflectivity  off  smoke  particles.  Battery  life  would  be  significantly  reduced  if  it  were 
pulsed  once  a  second,  and  it  is  normally  sampled  only  during  the  frame  in  which  a 
transmission  is  scheduled.  However,  the  photoelectric  smoke  detector  is  pulsed  every 
second  whenever  a  fire  alert  is  recognized,  because  transmissions  are  made  at  that  rate. 
The  sensor  sampling  and  processing  proceeds  in  several  stages.  Initially  all  analog  inputs 
are  read  by  the  microcontroller  A/D  converter  as  a  burst  and  the  raw  data  is  saved  in 
RAM.  One  of  these  measurements  is  an  internal  reference  voltage.  Since  all  A/D  readings 
are  ratio  metric  off  the  power  supply  voltage,  the  fixed  reference  voltage  allows  readings 
to  be  converted  to  an  absolute  voltage  where  required.  For  example,  because  the  oxygen 
sensor  generates  a  voltage  corresponding  to  the  percentage  of  oxygen  in  the  atmosphere, 
its  reading  must  be  converted  to  an  absolute  voltage  prior  to  calibration.  Other  readings, 
such  as  the  linear  temperature  sensor  and  the  thermistors  are  themselves  ratiometric,  and 
require  no  conversion  after  being  sampled  by  the  ratiometric  A/D  converter.  After  all 
sensors  have  been  sampled,  they  are  corrected  for  any  variation  in  supply  voltage,  and  are 
calibrated  using  the  calibration  coefficients  stored  in  EEPROM.  All  but  the  thermistors 
use  a  linear  scale  factor  and  bias  adjustment.  Because  the  thermistors  are  nonlinear 
devices,  the  EEPROM  data  is  a  series  of  calibration  points,  and  the  calibration  algorithm 
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interpolates  the  reading  between  these  points.  These  points  were  calculated  to  minimize 
the  peak  error  over  the  range.  The  calibrated  data  for  most  sensors  is  stored  directly  in  the 
transmit  buffer. 

The  fire  detection  algorithms  monitor  not  only  absolute  limits,  but  also  the  rate  of  change 
of  certain  parameters.  Both  short-term  and  long-term  exponential  filters  are  maintained 
for  most  of  the  sensors.  The  short-term  filters  (1/8  new  +  7/8  old)  remove  sample-to- 
sample  random  variations  from  readings  prior  to  comparison  with  threshold  limits.  This 
is  particularly  important  for  the  photoelectric  smoke  detector,  which  is  noisy  due  to  it 
operating  at  a  low  power  level  to  conserve  energy.  The  long-term  filters  (1/256  new  + 
255/256  old)  provide  a  baseline  to  gauge  the  rate- of- change  for  the  related  readings. 

After  the  readings  are  calibrated  and  the  digital  filters  are  updated,  the  new  readings  are 
compared  with  both  absolute  and  rate- of- change  limits  stored  in  EEPROM.  Should  any 
of  these  limits  be  exceeded,  the  corresponding  status  and  alert  bits  are  set.  Whenever  the 
threshold  comparisons  cause  a  status  change,  the  present  set  of  readings  will  be 
transmitted.  Transmissions  also  occur  at  a  more  rapid  rate  when  any  of  the  rate-of-change 
limits  are  exceeded.  Transmissions  occur  every  second  when  a  fire  alert  is  issued.  During 
a  fire  alert,  energy  conservation  becomes  secondary.  It  is  more  important  to  pass  as  much 
information  as  possible  to  the  Access  Point  because  the  survival  of  the  ship  is  at  stake. 

There  is  a  multi- criteria  selection  for  the  fire  alert  bit.  Two  bytes  in  EEPROM  have 
individual  bits  to  AND  each  of  the  fire  sensors  into  the  algorithm.  For  example,  if  the 
ionization  smoke  detector  and  high  temperature  are  selected,  then  both  of  these  sensors 
must  exceed  their  limits  before  the  fire  alert  is  set.  Other  thresholds  in  EEPROM 
determine  whether  the  individual  status  bits  are  set  for  exceeding  a  fixed  threshold  or 
whether  a  high  rate-of-change  has  been  detected.  Individual  options  in  the  multi- criteria 
bytes  select  either  a  high  temperature  limit  or  high  temperature  limit  OR  rapid 
temperature  rise.  This  option  was  included  to  prevent  false  alerts  when  an  Environmental 
Sensor  Cluster  is  mounted  just  inside  the  doorway  of  an  air-conditioned  space.  Opening 
the  door  could  cause  a  rapid  temperature  rise,  but  that  should  not  be  a  factor  in 
determining  a  fire  alert.  However,  a  rapid  temperature  rise  in  a  more  benign  location 
could  give  an  early  warning  that  a  fire  has  started.  The  multi-criteria  selection,  fixed,  and 
rate-of  change  thresholds  can  all  be  changed  via  the  Access  Point  to  give  maximum 
flexibility  in  establishing  fire  alert  conditions. 
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4.1.4  Sensor  Performance 

While  the  intent  was  just  to  measure  the  sensors  and  output  the  resulting  data,  it  was 
found  during  testing  that  several  of  the  sensors  needed  additional  processing.  The  carbon 
monoxide  and  oxygen  sensors  exhibited  significant  drift  after  initially  being  switched  on. 
It  could  take  these  sensors  many  minutes  to  stabilize  to  an  accurate  reading.  The  pressure 
and  flooding  sensors  stabilized  more  quickly  but  had  their  own  set  of  problems.  This 
section  describes  how  the  individual  sensor  characteristics  were  handled. 

Literature  from  Monox  indicates  it  could  take  a  long  time  for  that  carbon  monoxide 
sensor  to  stabilize  after  power  is  turned  on.  This  was  not  seen  during  development 
because  the  emulator  power  came  on  with  the  computer,  and  the  prototype  was  powered 
through  the  emulator  link.  Power  to  the  carbon  monoxide  sensor  remained  on  most  of  the 
time  during  code  development.  During  testing,  it  was  discovered  the  carbon  monoxide 
sensor  seemed  to  take  a  variable  length  of  time  to  stabilize,  depending  on  how  long 
power  was  off.  It  would  stabilize  within  minutes  when  power  was  removed  for  less  than 
an  hour,  but  would  take  much  longer  when  power  was  off  for  an  extended  period. 

Because  the  erroneous  values  would  corrupt  the  fire  detection  algorithms,  code  was 
developed  to  override  the  carbon  monoxide  data  sensor  until  the  sensor  had  stabilized. 
This  code  monitors  its  rate  of  change  after  power  is  switched  on,  and  substitutes  a  default 
value  until  the  rate  of  change  decreases  to  near  zero. 

Another  problem  testing  divulged  about  the  carbon  monoxide  sensor  was  stabilization  of 
the  zero  point.  This  sensor  is  capable  of  reading  to  5000  parts  per  million.  A  1%  bias 
error  can  cause  a  50  ppm  erroneous  positive  reading.  A  carbon  monoxide  bias  adjustment 
was  added  in  the  portion  of  EEPROM  that  can  be  updated  by  the  Access  Point  so  the 
carbon  monoxide  level  can  be  zeroed  if  necessary  during  operation. 

As  described  elsewhere,  the  oxygen  sensor  is  essentially  a  battery.  To  maximize  its 
operating  life,  the  oxygen  sensor  is  only  switched  on  while  the  Environmental  Sensor 
Cluster  is  communicating  with  an  Access  Point.  Like  an  ordinary  flashlight  battery,  the 
initial  output  from  the  oxygen  sensor  is  high,  and  it  takes  several  minutes  before  its 
output  decreases  to  an  accurate  value.  Code  similar  to  that  developed  for  the  carbon 
monoxide  sensor  was  added  to  override  the  oxygen  readings  until  they  have  stabilized. 
The  other  factor  to  consider  with  the  oxygen  sensor  is  that  its  output  will  slowly  decrease 
over  its  operating  lifetime.  It  will  require  periodic  calibration  to  maintain  high  accuracy. 

A  scale  factor  adjustment  was  added  in  the  portion  of  EEPROM  that  can  be  updated  by 
the  Access  Point  so  the  oxygen  sensor  can  be  readjusted  to  produce  an  accurate  reading  if 
necessary  during  its  operation. 

Long-term  control  loops  to  stabilize  the  carbon  monoxide  and  oxygen  readings  were 
initially  placed  in  the  Environmental  Sensor  Cluster  itself,  but  these  loops  could  have 
masked  slow  changes  in  the  environment.  Since  the  Access  Point  has  the  bigger  picture, 
and  can  correlate  readings  from  other  Environmental  Clusters  when  adjusting  these 
sensors,  it  was  given  the  responsibility  to  maintain  their  long-term  accuracy.  The  cluster 
only  handles  the  period  up  until  the  carbon  monoxide  and  oxygen  sensors  have  achieved 
initial  stabilization. 
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Both  the  ambient  pressure  sensor  and  the  differential  pressure  sensor  for  flooding  also 
have  stabilization  problems.  Both  produce  an  inaccurate  initial  reading  when  an 
Environmental  Sensor  Cluster  first  establishes  communication  with  an  Access  Point  and 
begins  sending  data.  Because  of  this,  their  first  readings  are  ignored  and  their  digital 
filters  are  initialized  after  their  readings  have  stabilized. 

While  testing  showed  the  differential  pressure  sensor  was  an  accurate  flooding  indicator, 
slight  instability  and  hysteresis  caused  the  zero- flood- level  reading  to  drift  slightly.  This 
was  certainly  within  the  expected  accuracy  of  the  sensor,  but  the  small  errors  with  no 
flooding  were  disconcerting.  A  low-speed  control  loop  was  added  to  drive  the  zero  level 
to  exactly  zero.  A  negative  reading  is  clamped  at  zero.  The  control  loop  is  inhibited  if  the 
flooding-sensor  reading  rises  above  2  inches,  or  is  increasing  at  a  large  rate.  This  control 
loop  keeps  the  flooding  readout  actively  zeroed  unless  an  actual  flooding  condition  is 
detected. 

A  similar  control  loop  was  considered  for  the  ambient  pressure  sensor  to  drive  it  to 
standard  atmospheric  pressure  at  sea  level,  but  the  sensor  used  for  this  application  did  not 
perform  as  expected.  While  identical  to  the  sensors  used  on  the  prototypes,  most  of  the 
sensors  installed  on  the  production  units  had  a  scale  factor  below  the  acceptable  range. 
Some  had  a  scale  factor  too  low  to  be  calibrated.  The  units  that  could  be  calibrated 
required  such  a  large  scale-factor  multiplication  that  their  readings  were  unstable. 

Without  further  investigation,  it  is  not  know  whether  the  problem  was  due  to 
contamination  getting  into  the  sensing  port  during  assembly,  or  whether  there  was  a 
production  lot  problem  from  the  manufacturer.  The  problem  was  not  investigated  further 
because  these  sensors  were  not  an  essential  part  of  the  sensor  Suite,  and  their 
disappointing  performance  would  not  compromise  the  overall  system  operation. 

4.1. 4.1  Power  Considerations 

Recognizing  that  it  is  essential  for  the  environmental  parameters  to  be  measured,  the  next 
most  important  factor  for  the  clusters  is  maximum  operating  life.  While  affected  by 
operating  modes  and  changes  in  the  environment,  the  Environmental  Sensor  Cluster 
battery  life  can  exceed  1  year.  However,  the  high  current  demand  for  sensors  now  used 
for  the  Structural  Sensor  Cluster  limits  its  battery  life  to  several  weeks.  Again,  this 
depends  on  the  operating  modes.  Extended  operation  of  the  Structural  Sensor  Cluster  in 
the  General  Quarters  mode  (with  sensors  on  continuously)  will  drain  the  battery  quickly. 
Both  sensor  clusters  have  the  ability  to  monitor  their  battery  condition,  and  maintenance 
personnel  can  be  informed  when  replacement  becomes  necessary. 

RSVP  incorporated  many  of  the  micropower  tricks  learned  during  the  IR&D  RQS 
project.  These  included  using  a  comparator  in  front  of  the  CMOS  input  for  an  oscillator 
to  insure  the  input  voltage  passes  through  the  “high  dissipation”  transition  region  quickly. 
Power  sequencing,  sleep  modes,  adjustable  clock  rates,  and  high-value  isolation  resistors 
were  all  used  to  full  advantage.  Low  supply  voltage  correlates  with  low  power 
consumption.  The  HC05  family  can  operate  down  to  3.0  wits.  Increasing  the  supply  to 
5.0  volts  could  double  the  microcontroller  throughput  and  increase  the  accuracy  of  its 
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A/D  converter,  but  the  tripled  power  consumption  was  unacceptable.  Another  factor 
considered  was  the  suite  of  sensors.  Standard  integrated  circuits  for  consumer  smoke  and 
ionization  alarms  are  designed  to  operate  from  a  9- volt  battery.  RSVP  includes  custom 
circuitry  to  duplicate  the  sensing  functions  of  these  devices  while  avoiding  the  higher 
supply  voltage  needed  by  the  standard  parts. 

All  sensor  cluster  circuitry  was  designed  to  operate  from  a  single  3.3-volt  supply.  The 
Environmental  Clusters  run  off  a  simple  series  pass  regulator  with  primary  power 
provided  by  three  Eveready  L91  AA  lithium  cells.  The  three  L91s  can  provide  over  10 
watt- hours  of  total  energy,  or  about  1- milliwatt  average  for  a  year.  Reducing  the 
background  transmit  duty  cycle  and  extending  the  power-down  sleep  interval  would 
extend  operating  life.  Each  of  these  intervals  can  be  programmed  via  the  RS232  serial 
link. 

The  Sarcos  strain  sensors  and  the  shock  and  navigation  sensors  selected  for  RSVP  need 
higher  voltages.  A  high-efficiency  switching  regulator  power  supply  was  designed  for  the 
Structural  Sensor  Cluster  to  provide  the  higher  voltages  needed  by  its  sensors.  For 
maximum  operating  life,  the  switching  regulators  are  only  switched  on  during  the  sensor 
measurements. 
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4,1,5  Firmware  Modules 

This  section  describes  the  RSVP  code  modules.  The  descriptions  for  each  module  begin 
with  the  filename  used  for  the  Environmental  Sensor  Cluster  code.  Several  modules,  such 
as  those  relating  to  the  RF  link,  are  identical  for  the  Structural  Sensor  Cluster.  Those  that 
have  similar  functions,  but  are  not  identical  have  the  underscore  replaced  with  a  dash 
for  the  corresponding  Structural  Sensor  Cluster  code  module. 

RSVP  EOS  /  RSVP-SOS  -  Environmental  /  Structural  Operating  System:  The 
Environmental  and  Structural  Operating  Systems  are  the  code  modules  that  are 
downloaded  into  the  microcontroller  EPROM.  The  source  code  for  these  modules 
provides  the  framework  for  all  sensor  cluster  firmware.  They  include  the  power-on 
initialization,  interrupt  processing,  overall  system  timing,  utility  functions,  and  several 
shared  tables  needed  by  other  firmware  modules.  All  other  firmware  modules  are 
included  in  the  firmware  assembly  by  references  in  the  operating  system  code  modules. 
Detailed  processing  functions  are  performed  by  several  of  the  firmware  modules  listed 
below. 

RSVP_CON  -  Constant  Assignments:  This  small  module  contains  the  I/O  port 
definitions  and  internal  register  addresses  for  the  68HC705B16  microcontroller.  While 
some  of  these  assignments  are  fixed  in  the  microcontroller  itself,  most  define  the 
electrical  I/O  interconnections  to  the  sensor  cluster  board. 

RSVP_RAM  -  RAM  Assignments:  This  module  defines  all  data  held  in  the 
microcontroller  random- access  memory.  Because  many  instructions  only  operate  on  data 
held  in  the  first  256  bytes  of  the  memory  map,  base-page  RAM  is  very  valuable.  Many 
addresses  in  the  base-page  have  multiple  uses,  depending  on  what  code  is  running.  For 
example,  the  array  space  used  for  the  sound  FFT  is  also  used  for  the  transmit  and  receive 
data  buffers.  Transient  data  parameters  have  unique  names,  and  are  mapped  into 
temporary  RAM  locations  that  were  selected  to  avoid  conflicts  while  those  parameters 
are  active.  The  microcontroller  stack  also  uses  base-page  RAM,  and  sufficient  space  must 
be  left  above  the  transient  data  to  allow  for  the  maximum  number  of  subroutine  calls. 
RAM  assignments  were  a  balancing  act  during  program  development,  and  several 
problems  were  traced  to  transient  data  being  stepped  on  by  the  stack.  Because  base-page 
RAM  is  very  limited,  only  critical  parameters  have  unique  base-page  RAM  assignments. 
The  functions  of  all  individual  status  flags  are  defined  under  each  status  data  byte  that 
holds  that  status  flag.  There  are  several  different  data  messages,  and  the  transmit  buffer 
data  organization  is  defined  for  each  of  the  messages.  To  minimize  RAM  usage, 
calibrated  sensor  readings  are  stored  directly  into  the  transmit  buffer  wherever  possible. 

RSVP_EEP  -  EEPROM  Assignments:  The  EEPROM  contains  all  data  that  can  be 
altered  after  the  microcontroller  is  programmed.  The  lower  portion,  which  cannot  be 
locked,  contains  the  system  operational  constants  that  can  be  changed  by  the  Access 
Point.  The  upper  region,  which  is  lockable,  contains  calibration  data  for  each  of  the 
sensors,  and  various  other  system  constants  that  may  be  altered  if  necessary.  These 
constants  were  originally  fixed  in  ROM,  but  were  moved  to  EEPROM  to  allow  them  to 
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be  changed  in  the  field  without  having  to  reprogram  the  microcontroller.  All  EEPROM 
data  is  initialized  from  ROM  the  first  time  the  microcontroller  is  powered  up  after  being 
programmed.  The  initial  calibration  values  are  necessary  for  the  sensors  to  be  “in  the 
ballpark”  before  the  actual  calibration  is  done.  All  EEPROM  data  can  be  accessed  and 
modified  via  an  RS232  link  to  a  laptop  computer. 

RSVP_CFG  -  Configuration  Monitor:  This  module  provides  the  means  to  interact  with 
either  the  Environmental  Cluster  or  the  Structural  Cluster  via  the  19.2K  RS232  link  to  a 
laptop  computer.  It  includes  commands  to  test  the  electronics,  calibrate  the  sensors,  and 
alter  any  of  the  constants  held  in  EEPROM.  A  section  of  this  document  details  the 
operation  of  the  Configuration  Monitor  for  both  kinds  of  Sensor  Cluster. 

RSVP_SYN  -  Synchronization:  This  module  is  certainly  the  most  complex  in  the  RSVP 
sensor  cluster  firmware.  Whenever  a  sensor  cluster  is  powered  in  the  acquisition  mode,  it 
must  establish  communication  with  an  Access  Point  to  begin  sending  data.  This  routine 
establishes  communication  with  an  Access  Point,  and  maintains  synchronization  as  long 
as  communication  with  that  Access  Point  is  feasible.  When  communication  is  lost,  it  tries 
to  establish  communication  with  another  Access  Point.  Failing  that,  the  Sensor  Cluster 
will  power  down  for  a  predetermined  sleep  interval  before  it  attempts  to  reestablish 
communication.  A  further  description  on  how  the  network  is  managed  can  be  found 
elsewhere  in  this  document. 

The  synchronization  routine  is  organized  as  several  interlocked  loops  that  are  called  when 
communication  must  be  established,  or  when  resynchronization  is  necessary.  The  outer 
loop  handles  the  overall  search  procedure.  It  orchestrates  listening  on  the  PSM  channel 
and  then  on  the  AP  channels.  The  actual  search  process  is  done  by  an  inner  loop  that  also 
handles  the  periodic  resynchronization.  Flags  determine  whether  it  is  PSM-monitor 
operation,  AP- monitor  operation,  or  a  periodic  resynchronization.  An  Access  Point 
header  is  identified  as  beginning  with  the  “FFOOFF”  pattern  with  opposite  parity.  To 
maintain  synchronization,  the  interval  timer  is  reset  immediately  after  an  Access  Point 
header  is  received.  Any  data  contained  in  the  message  is  processed  and  responded  to  after 
the  timing  reference  has  been  established. 

The  list  of  other  Access  Points  within  the  compartment  that  is  contained  in  an  Access 
Point  message  is  used  to  maintain  the  Sensor  Cluster’s  frequency  table.  The  received 
signal  strength  of  Access  Points  found  during  the  PSM  search,  but  not  indicated  as  being 
active  in  the  compartment,  is  decremented  at  each  resynchronization.  These  superfluous 
Access  Points  are  purged  from  the  cluster’s  frequency  table  individually  as  their  signal 
amplitudes  decrease  to  zero.  Eventually  only  Access  Points  active  in  that  compartment 
are  in  the  cluster’s  frequency  table,  sorted  by  received  signal  strength.  Access  Points 
active  in  the  compartment  that  were  not  found  during  the  PSM-channel  monitor  operation 
are  added  to  the  bottom  of  the  Sensor  Cluster’s  frequency  table.  When  communication  is 
lost,  the  table  is  used  to  re-establish  communication  with  another  Access  Point  quickly 
without  having  to  repeat  the  power- hungry  PSM-channel  monitor  operation. 
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RSVP_ADC  -  A/D  Conversion:  This  module  performs  the  sensor  scan  and  calibrates  the 
measurements  based  on  calibration  coefficients  stored  in  the  EEPROM.  It  also  maintains 
several  digital  filters  used  to  track  the  rate  of  change  of  certain  characteristics  of  the 
environment.  This  process  proceeds  in  several  stages.  First,  sensor  power  is  applied,  and 
sensors  are  scanned.  The  photoelectric  detector  is  only  switched  on  during  a  fire  alert  or 
if  a  transmission  is  scheduled  to  conserve  power.  Using  the  voltage  reference 
measurement,  a  correction  factor  is  calculated  for  those  readings  that  must  be  converted 
to  absolute  values,  and  those  readings  are  adjusted.  Then  all  sensor  readings  are 
calibrated  using  scale-factor  and  bias  numbers  stored  in  EEPROM.  The  thermistor 
readings  are  processed  differently  because  thermistors  are  not  linear  devices.  The 
EEPROM  contains  a  sequence  of  calibration  points  for  each  thermistor,  and  these 
readings  are  calibrated  by  interpolating  between  the  calibration  points.  As  each  of  the 
sensors  is  calibrated,  short-  and  long-term  exponential  digital  filters  are  updated  with  the 
new  data.  The  short-term  filter  removes  sample-to-sample  randomness  from  the  readings. 
The  long-term  filter  establishes  a  baseline  to  gauge  rate  of  change.  As  the  readings  are 
calibrated,  they  are  stored  in  the  transmit  buffer  to  prepare  for  the  next  transmission. 

RSVP_CHK  -  Check  Thresholds:  This  module  compares  all  sensor  readings  against 
limits  contained  in  EEPROM,  and  sets  status  and  alert  flags  for  those  readings  that 
exceed  their  limits.  This  routine  also  performs  redundancy  management  for  the  triplex 
habitation  thermistor  set.  When  readings  are  within  2  degrees  Centigrade,  an  average 
reading  is  calculated.  Averaging  of  the  closest  two,  or  mid- value  select  is  performed  as 
appropriate  when  the  readings  disagree  by  more  than  2  degrees  Centigrade. 

This  routine  checks  thresholds  for  both  absolute  limits,  and  rate  of  change  limits.  Status 
flags  are  set  whenever  a  threshold  is  exceeded.  A  fire  alert  can  be  issued,  depending  on 
which  sensors  were  selected  for  the  multi-criteria  fire  alert.  This  routine  also  maintains 
the  status  bits  that  determine  sample  rate.  Whenever  a  status  bit  changes,  it  schedules 
immediate  transmission  of  that  fact.  Hysteresis  is  used  on  all  status  bits  to  prevent 
wasteful  transmissions  when  a  reading  sits  right  at  a  threshold. 

RSVP_SND  -  Sound  Event  Processing:  This  module  contains  subroutines  to  sample  the 
audio  channel  and  process  the  resulting  data.  The  microphone  is  sampled  64  equally- 
spaced  times  over  a  10- millisecond  interval.  The  maximum  and  average  peak-to-peak 
values  of  the  input  waveform  are  calculated  for  readout  and  automatic  gain  control.  If  the 
amplitude  of  the  event  is  large  enough,  a  32-point  FFT  is  calculated  and  stored  in  the 
transmit  buffer  for  later  transmission  to  the  Access  Point.  For  best  resolution,  the  FFT 
power  data  is  normalized,  and  the  scaling  information  is  included  in  the  sound  event 
message. 

RSVP_RF  -  RF  Control:  This  module  sets  the  RF  frequency  synthesizer  to  the  selected 
channel.  There  are  142  channels.  The  channel  number  is  used  as  an  index  into  the 
frequency  tables.  Different  tables  are  used  for  transmit  and  receive  frequency  settings  to 
allow  the  offset  for  the  IF  amplifier  in  the  receiver.  The  frequency  data  is  “bit  banged” 
out  to  the  synthesizer  through  several  I/O  lines  to  set  the  frequency.  A  short  delay  allows 
the  synthesizer  to  stabilize  before  the  receiver  or  transmitter  is  switched  on. 
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RSVP_MSG  -  Receive  Message  Processing:  This  module  processes  any  commands 
received  from  the  Access  Point.  The  messages  are  either  requests  for  data  or  contain  data 
to  programmed  into  the  EEPROM.  A  table  near  the  end  of  RSVP_EOS  defines  the 
recognized  messages,  their  lengths,  and  whether  they  will  be  accepted  in  broadcast  mode. 
The  Environmental  Sensor  Cluster  accepts  the  following  message  types  from  the  AP: 

40]  6  Sync  Reference  -  standard  AP  header  that  contains  only  the  frequency 

table 

4 1 1 6  Slot  Assignment  -  byte  1 6  =  slot  # 

42 16  Data  Request  -  byte  16  =  type  of  data  requested  (broadcast  mode 

accepted) 

43 16  Set  Threshold  Byte  -  used  to  change  a  single  parameter  in  EEPROM 
44 16  Multi-byte  Downlink  -  used  to  change  a  block  of  data  in  EEPROM 

45)6  Kickoff  -  causes  the  cluster  to  migrate  to  another  AP  (broadcast 

mode  accepted) 

RSVP_XMT  -  Transmit  Data:  This  module  transmits  all  possible  data  messages.  The 
Transmit  subroutine  starts  by  filling  the  transmit  buffer  with  the  any  data  required  for  that 
particular  message  type,  and  then  calls  the  shared  Transmit  Data  subroutine  to  output  the 
data  from  the  transmit  buffer  to  the  radio.  All  transmitted  messages  begin  with  a  fixed 
FF00FF  header  pattern  for  message  synchronization.  55FF  was  added  in  front  of  this 
standard  header  pattern  to  help  the  radio  lock  to  the  message.  This  routine  is  also  used  to 
output  data  in  ASCII  format  for  testing  and  calibration  while  running  the  Configuration 
Monitor. 

RSVP_TBL  -  CRC  Table:  This  module  contains  data  used  by  the  Transmit  Data 
subroutine  to  calculate  the  1 6-bit  cyclic  redundancy  check  characters  added  to  the  end  of 
a  message. 

RSVP_FRQ  -  Frequency  Tables:  This  module  contains  the  bit  patterns  that  are  sent  to 
the  frequency  synthesizer  for  each  channel  number. 

RSVP_STR  -  Strain  Sensor  Code:  This  module  contains  code  to  sample  the  Sarcos 
strain  sensors.  It  first  sends  a  pattern  of  pulses  to  the  Sarcos  sensors  to  cause  them  to 
make  a  reading,  as  defined  in  the  Sarcos  data.  It  then  reads  the  data  from  both  sensors 
over  their  serial  interface.  Each  data  bit  is  center  sampled  for  maximum  noise  rejection. 
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4. 1  *6  Environmental  Cluster  Configuration  Monitor 

A  simple  interactive  monitor  offers  test  modes  useful  for  calibration,  and  allows 
calibration  coefficients  and  system  constants  to  be  altered  The  monitor  is  automatically 
entered  at  power-up  when  the  EEPROM  is  unlocked.  At  a  minimum,  the  Sensor  Cluster 
serial  number  must  be  entered,  and  the  protected  portion  of  the  EEPROM  locked.  After 
the  EEPROM  is  locked,  it  is  still  possible  to  for  the  Sensor  Cluster  to  enter  the  monitor. 
When  power  is  cycled,  the  Sensor  Cluster  will  issue  the  prompt  “RSVP”  over  its  serial 
port  at  19.2K  baud  with  the  radio  off.  If  the  Sensor  Cluster  receives  a  space  character 
within  2  seconds  of  the  prompt,  and  “RSVP”  within  the  next  10  seconds,  then  it  will  enter 
the  monitor  mode.  If  anything  other  than  the  space  character  is  received  within  the  first 
two  seconds,  or  anything  other  than  “RSVP”  is  received  within  the  next  10  seconds,  the 
Sensor  Cluster  transmits  “END”  and  enters  its  operational  mode.  The  Sensor  Cluster  does 
not  check  for  entry  into  the  monitor  mode  again  unless  power  is  removed  for  several 
seconds. 


The  following  commands  are  available  in  monitor  mode: 

?  Sensor  Query  -  outputs  standard  environmental  message  data  in  ASCII  format 

Sc  Diagnostic  Query  -  outputs  the  diagnostic  message  data  in  ASCII  format 

!  Monitor  the  sound  channel  -  outputs  sound  event  message  data  in  ASCII  format  (hit  a  key  to  exit) 

A  Turn  sensor  power  ON 

_  Turn  sensor  power  OFF 

>  Increase  microphone  input  analog  gain  (7  is  maximum) 

<  Decrease  microphone  input  analog  gain  (0  is  minimum) 

{  *  Switch  Ionization  sensor  test  mode  ON  (useful  during  calibration) 

}  Switch  Ionization  sensor  test  mode  OFF  (useful  during  calibration) 

-  Read  and  display  Sarcos  strain  sensors  (only  useful  for  testing  the  Sarcos  data  interface) 

Q  Query  selected  sensor  while  EEPROM  calibration  data  is  displayed 

Ctrl  C  Carbon  monoxide  test  -  generates  simulated  CO  for  10  seconds  &  displays  raw  readings 

Ctrl  I  Ionization  smoke  sensor  test  -  pulses  test  input,  displays  raw  Sc  calibrated  readings  (off. .  .on, .  off) 

Ctrl  R  Reset  all  sensor  short-term  and  long-term  digital  filters 

Ctrl  S  Scan  sensors  and  output  uncalibrated  readings  contained  in  the  A/D  buffer 

Ctrl  L  Lock  EEPROM 

Ctrl  U  Unlock  EEPROM  (requires  “Y”  acknowledgement  before  the  unlock  is  performed) 

Ctrl  Z  Exit  Monitor  (also  insures  EEPROM  is  locked) 


Calibration  data  in  locked  EEPROM  may  be  entered  or  modified  using  the  following 
commands: 


# 

@ 

1 

2 

3 

C 

F 

H 

I 

L 

O 

P 

S 


4-byte  factory  serial  number 
PSM  channel  assignments  (default  are  1  and  81) 
thermistor#!  (7-byte  calibration  table) 
thermistor  #2  (7-byte  calibration  table) 
thermistor  #3  (7-byte  calibration  table) 
carbon  monoxide  (scale  factor  and  bias) 
flooding  sensor  (scale  factor  and  bias) 
humidity  sensor  (scale  factor  and  bias) 
ionization  smoke  detector  (scale  factor  and  bias) 

6  bytes  for  physical  location  parameters  (optional) 
oxygen  sensor  (scale  factor  and  bias  for  each) 
pressure  sensor  (scale  factor  and  bias) 
photoelectric  smoke  detector  (scale  factor  and  bias) 


‘Q”  reads  raw  Sc  calibrated  temperature 
"Q”  reads  raw  &  calibrated  temperature 
5Q”  reads  raw  Sc  calibrated  temperature 
£Q”  reads  raw  Sc  calibrated  CO  level 
£Q”  reads  raw  &  calibrated  flooding  level 
£Q”  reads  raw  Sc  calibrated  humidity 
£Q”  reads  raw  Sc  calibrated  smoke  level 

£Q”  reads  raw  &  calibrated  oxygen  for  each 
£Q”  reads  raw  Sc  calibrated  pressure 
‘Q”  reads  raw  &  calibrated  smoke  level 
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T  linear  temperature  sensor  (scale  factor  and  bias)  “Q”  reads  raw  &  calibrated  temperature 

W  wide  range  thermistor  (7-byte  calibration  table)  “Q”  reads  raw  &  calibrated  temperature 

K  provides  access  to  all  system  constants  that  can  be  modified 

Thresholds  and  operational  parameters  in  unlocked  EEPROM  may  be  entered  or 
modified  using  the  following  commands: 

+  configuration  flags  (selects  which  oxygen  sensors  are  enabled) 

$  oxygen  sensor  scale -factor  adjustment  and  carbon  monoxide  bias  adjustment 

%  threshold  limits  for  all  sensors 

M  multi-criteria  fire  selection  bytes  (logic  1  selects  AND  into  fire  alert) 

X  transmit  parameters  (time  between  scheduled  &  high-rate  transmissions) 

Z  sleep  interval  after  AP  search  fails  in  32-second  increments 

Only  the  thresholds  and  operational  parameters  can  be  modified  via  the  AP. 

EEPROM  data  is  entered  via  hexadecimal  characters.  Data  can  be  edited  using  TAB  to 
skip  fields,  and  BACKSPACE  to  correct  entries.  Editing  the  displayed  set  of  EEPROM 
parameters  is  terminated  with  the  ENTER  key.  The  data  displayed  is  written  to  EEPROM 
at  that  time.  Only  valid  hexadecimal  characters  will  be  accepted  with  one  exception.  If 
“Q”  is  entered  immediately  after  sensor  calibration  data  is  displayed  (with  cursor  still  at 
the  beginning  of  the  line),  that  sensor  will  be  sampled  and  the  raw  and  calibrated  readings 
for  it  will  be  displayed.  This  function  is  useful  during  test  and  calibration  of  the  sensors. 

4.1. 6.1  Uncalibrated  Dump  of  A/D  buffer  with  Ctrl  “S”  Command 

XX  2X  Vref  A/D  reading 

XX  sound  input  (single  reading  not  useful) 

XX  ionization  smoke  detector  A/D  reading 

XX  photoelectric  smoke  detector  A/D  reading 

XX  carbon  monoxide  detector  A/D  reading 

XX  linear  temperature  sensor  A/D  reading 

XX  habitation  thermistor  #1  A/D  reading 

XX  wide-range  thermistor  A/D  reading 

XX  oxygen  sensor  #  1  A/D  reading 

XX  oxygen  sensor  #2  A/D  reading 

XX  absolute  pressure  sensor  A/D  reading 

XX  flooding  differential  pressure  sensor  A/D  reading 

XX  hatch  status  input  A/D  reading 

XX  scaled  battery  voltage  2  A/D  reading 

XX  radio  signal  strength  indicator  A/D  reading 

XX  scaled  battery  voltage  1  A/D  reading 

XX  habitation  thermistor  #2  A/D  reading 

XX  habitation  thermistor  #3  A/D  reading 

XX  sensor  1  power  A/D  reading 

XX  sensor  2  power  A/D  reading 

XX  photoelectric  LED  drive  level  A/D  reading 

XX  carbon  monoxide  counter  control  loop  A/D  reading 
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4.1. 6.2  Environmental  Cluster  Standard  Data  Message 

32  Message  Type  for  Standard  Data  Message 

XX  LS  Byte  of  32 -bit  cluster  ID  number 

XX  Alert  Status  byte 

bit  7  (8016)  =  fire  alert 
bit  6  (40!  &)  -  flooding  alert 

bit  5  (20i6)  =  high  temperature  or  rapid  increase  alert 
bit  4  (IO15)  =  high  carbon  monoxide  or  rapid  increase  alert 
bit  3  (08i6)  =  pressure  indicator  alert 
bit  2  (04i6)  =  open  hatch  status  alert  (1  for  >  open  threshold) 
bit  1  (02j6)  -  closed  hatch  status  alert  (1  for  <  closed  threshold) 
bit  0  (01|6)  =  low  primary  battery  alert 
XX  Health  Status  byte 

bit  7  (80i  e)  “  low/high  power  supply  voltage 
bit  6  (40j  e)  =  habitation  thermistor  discrepancy 
bit  5  (20t  $)  =  linear  temperature  above  high  threshold 
bit  4  (10ie)  =  linear  temperature  below  low  threshold 
bit  3  (08}  e)  -  RF  signal  strength  below  low  threshold 
bits  2,1,0  =  sound/vibration  input  gain 
XX  Multi-Criterion  fire  status  bits 

bit  7  (80i  6)  =  photoelectric  smoke  detector  level  OR  rapid  Increase 
bit  6  (40|6)  =  ionization  smoke  detector  level  OR  rapid  change 
bit  5  (20ie)  =  high  temperature  OR  rapid  increase  in  temperature 
bit  4  (lOig)  ~  high  temperature  reading  (no  rate  of  increase  check) 
bit  3  (08j  $)  =  high  carbon  monoxide  level  OR  rapid  increase 
bit  2  (04}  6)  -  low  oxygen  level  OR  rapid  decrease 
bit  1  (02}  6)  =  high  humidity  level  OR  rapid  increase 
bit  0  (0116)  =  rapid  change  on  any  fire  sensor 
XX  Diagnostic  status  bits 

bit  7  (80}  s)  —  02  sensor  2  is  selected  (0  for  02  sensor  1) 

bit  6  (40j  e)  =  secondary  battery  below  threshold 

bit  5  (20}  6)  =  photodetector  LED  drive  error 

bit  4  (10is)=  CO  detector  counter  loop  saturation 

bit  3  (08}  e)  =  sensor  power  low  voltage 

bit  2  (04}  6)  -  sensor  1  on  low  voltage 

bits  1,0  =  thermistor  discrepancy:  1 1=#3  bad,  10=#2  bad,  01=#1  bad,  00=A11  OK 


XX 

Battery  Input  1  (from  PMM) 

V  =  3.3  x  (reading  /  1 28) 

XX 

Linear  Temp  Sensor  Level 

deg  C  =  (reading  -  40)  /  2 

XX 

Habitation  Temperature  Voted  Sum 

deg  C  =  (reading  -  40)  /  2 

XX 

Habitation  Temperature  256-second  average 

deg  C  =  (reading  -  40)  1 2 

XX 

Wide  Range  Temp  Sensor  reading 

deg  C  -  2  x  reading 

XX 

Humidity  Sensor  8-second  average 

%  relative  humidity  =  (reading-  50) 

XX 

Carbon  Monoxide  Sensor  8 -second  average 

CO  ppm  =  5x  (reading  -  10) 

XX 

Selected  Oxygen  Sensor  8-second  average 

Oxygen  %  =  reading  /  10 

XX 

Ionization  Smoke  Detector  Level  . 

nominal  =  200,  test  =  100 

XX 

Photodetector  Smoke  Detector  8-sample  average 

nominal  =  50,  test  =100 

XX 

Flooding  Indicator 

depth  inches  =  (reading  - 10)  /  4 

XX 

Pressure  Sensor  Level 

PSI  =  reading  /  5 

XX 

RSSI  (received  signal  strength  Indicator) 

V  =  3.3  x  (reading  / 256) 

XX 

Present  Sound  Signal  Level  (not  valid  In  monitor) 

relative  level  (varies  with  AGC) 

XX 

XXXX 

CRLF 

Average  Sound  Signal  Level  (not  valid  In  monitor) 
16-bit  CRC 

(Appended  only  In  Monitor  Mode) 

relative  level  (varies  with  AGC) 
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4.1.6.3  Environmental  Cluster  Sound  Event  Message 


33  Message  Type  for  Sound  Event 

XX  LS  Byte  of  32-bit  cluster  ID  number 
XX  Alert  Status  byte 

bit  7  (80i6)  =  fire  alert 
bit  6  (40i6>  =  flooding  alert 

bit  5  (20i6)  =  high  temperature  or  rapid  increase  alert 
bit  4  (1 0i6)  =  high  carbon  monoxide  or  rapid  increase  alert 
bit  3  (08)6)  =  pressure  indicator  alert 

bit  2  (04i6)  =  open  hatch  status  alert  (1  for  >  open  threshold) 
bit  1  (02]  6)  =  closed  hatch  status  alert  (1  for  <  closed  threshold) 
bit  0  (Oli  5)  =  low  primary  battery  alert 

NOTE:  The  alert  status  byte  reads  00H  while  in  the  configuration  monitor  test  mode 
XX  Health  Status  byte 

bit  7  (80)6)  =  low/high  power  supply  voltage 
bit  6  (40j6)  =  habitation  thermistor  discrepancy 
bit  5  (20ie)  =  linear  temperature  above  high  threshold 
bit  4  (10ie)  —  linear  temperature  below  low  threshold 
bit  3  (08i6)  =  RF  signal  strength  below  low  threshold 
bits  2,1,0  =  sound/vibration  input  gain 

NOTE:  Only  the  input  gain  is  valid  while  in  the  configuration  monitor  test  mode 
XX  Sound/vibration  peak-to-peak  amplitude 

XX  Sound/vibration  running  average 

XX  FFT  scale  factor  adjustment 

XX  Bin  number  of  strongest  FFT  component 

XX  Amplitude  of  strongest  FFT  component 
XX  Bin  number  of  2nd  strongest  FFT  component 
XX  Amplitude  of  2nd  strongest  FFT  component 

XX  32  Hexadecimal  characters  string  indicating  FFT  bin  amplitude  0-F 
XX  (there  are  no  spaces  between  these  ASCII  characters  in  the  monitor  mode) 

XX 

XX 

XX 

XX 

XX 

XX 

XX 

XX 

XX 

XX 

XX 

XX 

XX 

XX 

XXXX  16-bit  CRC 

CRLF  (Appended  only  in  Monitor  Mode) 
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4.1. 6,4  Environmental  Cluster  Diagnostic  Message 

34  Message  Type  for  Diagnostic  Data 


XX 

XX 


XX 


XX 

XX 


LS  Byte  of  32 -bit  cluster  ID  number 
Alert  Status  byte 
bit  7  (80j  e)  “  fire  alert 
bit  6  (40f  e)  -  flooding  alert 

bit  5  (20]  e)  =  high  temperature  or  rapid  increase  alert 
bit  4  (10]  6)  =  high  carbon  monoxide  or  rapid  increase  alert 
bit  3  (08i6)  =  pressure  indicator  alert 
bit  2  (04] $)  =  open  hatch  status  alert  (I  for  >  open  threshold) 
bit  1  (02j  e)  =  closed  hatch  status  alert  (1  for  <  closed  threshold) 
bit  0  (01]  $)  =  low  primary  battery  alert 
Health  Status  byte 

bit  7  (80]  s)  -  low/high  power  supply  voltage 
bit  6  (40]  5)  =  habitation  thermistor  discrepancy 
bit  5  (20]  6)  =  linear  temperature  above  high  threshold 
bit  4  (10]  e)-  linear  temperature  below  low  threshold 
bit  3  (08j  e)  =  RF  signal  strength  below  low  threshold 
bits  2,1,0  =  sound/vibration  input  gain 

2X  Comparator  LI 82  volt  reference  (uncorrected)  (used  to  calculate  actual  Vcc) 
Diagnostic  status  bits 

bit  7  (80]  6)  =  02  sensor  2  is  selected  (0  for  02  sensor  1) 

bit  6  (40]  5)  =  secondary  battery  below  threshold 

bit  5  (20]  e)  =  photodetector  LED  drive  error 

bit  4  (10]g)  =  CO  detector  counter  loop  saturation 

bit  3  (08]  e)  =  sensor  power  low  voltage 

bit  2  (04j 6)  =  sensor  1  on  low  voltage 

bits  1,0  =  thermistor  discrepancy:  1 1=#3  bad,  10=#2  bad,  01=#1  bad,  00=AI1  OK 


XXXX 

CRLF 


PMM  Battery  input  2  adjusted  reading 
Habitation  thermistor  1  calibrated  reading 
Habitation  thermistor  2  calibrated  reading 
Habitation  thermistor  3  calibrated  reading 
Photodetector  LED  source  level 
Humidity  sensor  256-second  running  average 
Carbon  Monoxide  Sensor  256-second  average 
Selected  Oxygen  Sensor  256-second  average 
Ionization  Smoke  Detector  256-second  average 
Photodetector  Smoke  Detector  256-second  average 
Oxygen  sensor  1  calibrated  reading 
Oxygen  sensor  2  calibrated  reading 
Hatch  status  (external  Input) 

Sensor  power  1  “ON”  voltage 
Switched  sensor  power  “ON”  voltage 
Sync  quality  status 
Oscillator  start-up  delay 
16-bit  CRC 

(Appended  only  in  Monitor  Mode) 


V  -  3.3  x  (reading  /  128) 
deg  C  =  (reading  -  40)  /  2 
deg  C  =  (reading  -  40)  /  2 
deg  C  -  (reading  -  40)  1 2 

V  =  3.3  x  (reading  /  256) 

%  relative  humidity  ~  reading  -  50 
CO  ppm  =5x  (reading  -  10) 
Oxygen  %  =  reading  /  10 
nominal  =  200,  test  -  100 
nominal  =  50,  test  =100 
Oxygen  %  =  reading  /  10 
Oxygen  %  =  reading  /  10 

V  =  3.3  x  (reading  /  256) 

V  =  3.3  x  (reading  /  256) 

V  =  3.3  x  (reading  /  256) 
unitless  quantity 

time  =  reading  x  138  ps 
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4.1.6.5  Environmental  Cluster  EEPROM  Calibration  Data 
NOTE:  The  first  31  bytes  cannot  be  locked,  and  can  be  modified  by  the  AP 
4.1.6.5.1  Environmental  Cluster  Control  (Modifiable  By  The  AP) 


Address 

0101 


0102 


0103 

0104 

0105 

0106 

0107 


Access  Parameter  (default  values  are  in  hexadecimal) 

+  Configuration  Flags 

First  byte  of  configurations  flags 
bit  7  (80)  6)  -  enable  respond  to  data  request  in  any  BOD 

bit  6  (40!6)  =  set  humidity  flag  if  high/low  (1/0) 
bits  5,4,3  select  sound  AGC  level  (100  =  mid  range) 
bit  2  (04]6)  =  select  oxygen  sensor  #2  for  output  (0=#1) 
bit  1  (02!6)  =  enable  oxygen  sensor  #2 
bit  0  (01 16)  =  enable  oxygen  sensor  #1 
default  =  21 16:  AGC  mid-range,  oxygen  #1  enabled 
Second  byte  of  configurations  flags 
bit  7  (80)6)  =  transmit  diagnostic  message  @  every  re -sync 
bit  6  (40i6>  -  inhibit  sound  level  interrupt 
all  other  bits  not  used 
default  =  80j6:  diagnostic  transmit  enabled 
Z  Sleep  interval  if  AP  search  fails  (N  x  32  sec) 

default  =  02] 5:  64  seconds 
X  Transmit  parameters 

Number  of  seconds  between  scheduled  transmissions 
default  =  0A  ]  6: 1 0  seconds  (range  is  5  to  50) 

Number  of  seconds  between  fast  transmissions 
default  =  02j6:  2  seconds  (range  is  1  to  scheduled  transmit  rate) 

$  Calibration  adjustments  -  allows  the  AP  to  adjust  a  drifting  sensor 

Oxygen  sensor  scale -factor  adjustment 
default  =  80]  5:  gain  X  1.0  (X  =  N/128) 

Carbon  monoxide  bias  adjustment 
default  =  80j 5:  zero  bias  (128  +/-  N  in  5  ppm  steps) 


54 


NSWCCD-TR-2003/02 


4.1.6.5.2  Environmental  Cluster  Alert  Thresholds  (Modifiable  By  TheAP) 


Address  Access 
M 

0108 


0109 


% 


010A 

010B 

010C 

010D 

010E 

010F 

0110 

0111 

0112 

0113 

0114 

0115 

0116 

0117 


Parameter  (default  values  are  in  hexadecimal) 

Multi-criteria  fire  selection  bits 

FIRE  ALERT  multi-criterion  selection  #1 

bit  7  (BOie)  =  AND  photoelectric  smoke  into  fire  alert 
bit  6  (40j6)  =  AND  ionization  smoke  into  fire  alert 
bit  5  (20ig)  =  AND  high  temp  OR  rapid  rise  into  fire  alert 
bit  4  (10,6)  =  AND  high  temperature  into  fire  alert 
bit  3  (08  ie)  =  AND  high  carbon  monoxide  into  fire  alert 
bit  2  (04, 6)  =  AND  low  oxygen  reading  into  fire  alert 
bit  1  (02j6)  =  AND  high  humidity  into  fire  alert 
bit  0  (01  =  not  used 

default  ^SOie:  ionization  AND  fast  temperature  rise 
FIRE  ALERT  multi-criterion  selection  #2 

bit  7  (80] 6)  =  AND  photoelectric  smoke  into  fire  alert 
bit  6  (40,6)  =  AND  Ionization  smoke  into  fire  alert 
bit  5  (20)6)  =  AND  high  temp  OR  rapid  rise  Into  fire  alert 
bit  4  (10ie)  =  AND  high  temperature  into  fire  alert 
bit  3  (08,6)  =  AND  high  carbon  monoxide  Into  fire  alert 
bit  2  (04, 5)  =  AND  low  oxygen  reading  into  fire  alert 
bit  1  (02,6)  =  AND  high  humidity  into  fire  alert 
bit  0(01,6)  =  not  used 

default  =  C0,e:  ionization  AND  photoelectric  smoke  detectors 
Threshold  parameters 
Linear  temperature  sensor  low  threshold 
default  =  3C,6:  10  degrees  C  (#  =  40  +  2*C) 

Linear  temperature  sensor  high  threshold 
default  =  78,6:  40  degrees  C  (#  =  40  +  2*€) 

Habitation  thermistors  high  ALERT  threshold 
default  =  78,6-  40  degrees  C  (#  =  40  +  2*C) 

Habitation  rate  of  increase  ALERT  threshold  (change  over  4  minutes) 
default  =  06,6:  +3  degrees  Increase  above  average  (#  =  2*C) 

Photoelectric  smoke  detector  high  ALERT  threshold 
default  =  4B,6:  75  mid  range  (nominal  =  50?  test  =  100) 

Photoelectric  smoke  detector  rate  ALERT  threshold  (change  over  4  minutes) 
default  =  05,6-  10%  change  (#  -  %  of  test  range/10) 

Ionization  smoke  detector  low  ALERT  threshold  (inverse) 
default  =  96,6:  150  mid-range  (nominal  =  200,  test  =  100) 

Ionization  smoke  detector  rate  ALERT  threshold  (change  over  4  minutes) 
default  =  0A,e:  10%  change  (#  =  %  of  test  range) 

Carbon  monoxide  high  ALERT  threshold  (FE  for  no  ALERT) 
default  =  10,6:  30  ppm  (#  =  10  +  5*ppm) 

Carbon  monoxide  rate  ALERT  threshold  (FE  for  no  ALERT) 
default  =  03,6:  15  ppm  Increase  above  average  (#  =  5*ppm) 

Oxygen  sensor  low  ALERT  threshold  (01  for  no  ALERT) 
default  =  BE16:  19%  {#  =  10*02%) 

Oxygen  sensor  rate  of  decrease  ALERT  threshold  (change  over  4  minutes) 
default  =  04,6:  0.4%  below  average  (#  =  10*02%) 

Humidity  sensor  high/low  ALERT  threshold 
default  =  46,6:  20%  (#  =  %H  +  50) 

Humidity  sensor  rate  of  change  ALERT  threshold  (change  over  4  minutes) 
default  =  04, 6:  4%  change  from  average  (#  =  %H) 
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0118 
0119 
01 1A 
01  IB 

one 

01  ID 
01  IE 
01  IF 


Flooding  sensor  high  ALERT  threshold  (FE  for  no  ALERT) 
default  =  1Ai6:  4  inches  (#  =  10  +  4*inches) 

Flooding  sensor  rate  of  increase  threshold  (change  over  4  minutes) 
default  =  04 16:  1  inch  above  average  (#  =  4*inches) 

Pressure  sensor  high  ALERT  threshold  (FE  for  no  ALERT) 
default  =  50] 6-  16  psi  (#  =  5*psi) 

Hatch  open  ALERT  threshold  (FE  for  no  ALERT) 
default  -  FEj6:  disabled  (#  -  2.55  *  %V  @  open) 

Hatch  closed  &  locked  ALERT  threshold  (01  for  no  ALERT) 
default  =  01 ,6:  disabled  (#  =  2.55  *  %V  @  locked) 

Battery  #1  low  ALERT  threshold  (01  for  no  ALERT) 
default  =  98 16:  3.9V  (#  =  39*V) 

Battery  #2  low  threshold  (01  to  disable) 
default  -  01 16:  disabled  (#  -  39* V) 

RF  signal  strength  low  threshold 
default  =  80j  6:  half  scale  (#  =  77* V) 
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4.1. 6.5.3  Environmental  Cluster  Locked  Calibration  Coefficients 

Address  Access  Parameter  (default  values  are  in  hexadecimal) 


0120  # 

0124  L 

01 2A  @ 

012C  T 

012E  1 

0135  2 

013C  3 

0143  W 

01 4A  P 

014C  F 

01 4E  H 

0151  S 

0153  I 

0155  C 

reference) 

0157  O 


Sensor  Cluster  4-byte  serial  number 
default  =  52535650)6  before  actual  cluster  S/N  is  programmed 
Sensor  Cluster  6-byte  physical  location  reference 
default  =  all  bytes  cleared  (not  used) 

PSM  channel  numbers  —  can  be  changed  if  required  due  to  interference 
default  =  01 ,6j  51)6:  Primary  PSM  #1,  Secondary  PSM  #81 
Linear  temperature  sensor  calibration  scale  factor  &  bias 
default  =  76,6, 15,6:  (gain  X  0.92,  +21  bias)  0C=.25V,  100C=3.05V 
Habitation  thermistor  #1  7 -byte  calibration  table 
default  =  0E,6,23!6, 4916)  7A16,  A616,  C7I6,  DD,6 
Habitation  thermistor  #2  7 -byte  calibration  table 
default  =  0EI6, 23!6, 49, 6, 7A16,  A6I6,  C7i6,  DD16 
Habitation  thermistor  #2  7 -byte  calibration  table 
default  =  0E,6, 2316, 49]6, 7AI6,  A616,  C716,  DD!6 
Wide-range  thermistor  7 -byte  calibration  table 
default  =  0116, 0BI6, 31, 6, 7A,6l  9BI6,  DC,6,  ED,6 
Pressure  sensor  calibration  scale  factor  &  bias 
default  =  80,6, 00, 6:  (gain  X  1.0,  zero  bias) 

Flooding  differential  pressure  sensor  scale  factor  &  bias 
default  =  98,6,  E2,6:  (gain  X  1.19,  -30  bias) 

Humidity  sensor  scale  factor  &  bias,  stop  count 
default  =  CO, e,  E8,6, 0B: (gain  X  1.5,  -24  bias,  1 1  cycles) 

Photoelectric  smoke  detector  scale  factor  &  bias 
default  =  8Cie,  C8,6:  (gain  X  1.09,  -56  bias) 

Ionization  smoke  detector  scale  factor  &  bias 
default  =  9Ai6,  28)6:  (gain  X  1 .20,  +40  bias) 

Carbon  monoxide  detector  scale  factor  &  bias 
default  =  A2i6,  98,6'.  (gain  X  1.27,  -104  bias  removes  1.18V 

Oxygen  sensors  scale  factor  &  bias  for  both  sensors 
default  =  90,6,  00,6,  90,6,  00i6:  (gain  X  1.13,  zero  bias  for  both) 
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4.1. 6.5.4  Environmental  Cluster  Locked  System  Constants 

Address  Access  Parameter  (default  values  are  in  hexadecimal) 

K  System  Constants  -  all  system  constants  are  accessed  as  one  string 
015B  Control  flags 

bit  7  (80i6)  =  select  transmit  data  in  ASCII  mode 

bit  6  (40]  6)  =  no  CRC  check  on  received  data 

bit  5  (20]  5)  ~  no  flooding  sensor  bias  drift  compensation 

all  other  bits  not  used 

default  =  00)6:  no  options  selected 

01 5C  Minimum  sound  Vpp  for  a  sound  message  to  be  sent 

default  =  40  ]6 

01 5D  Default  AGC  value  if  AP  setting  received  from  AP  is  invalid 

default  =  20]  6:  midrange 

01 5E  Number  of  re -sync  tries  before  moving  to  next  AP 

default  =  04]$:  three  tries  (tries  =  N-l) 

01 5F  Number  of  re -sync  cycles  before  “aging”  frequency  table 

default  =  09j6-  wait  for  9  successful  re-sync  cycles 
0 1 60  Number  of  re -sync  cycles  before  02  sensor  turns  ON 

default  =  02]  6:  wait  for  2  successful  re -sync  cycles 
0161  Slowest  background  transmit  rate  (seconds) 

default  =  32 1 6:  50  seconds  maximum  between  background  transmissions 
0162  Fastest  background  transmit  rate  (seconds) 

default  =  05 16:  5  seconds  minimum  between  background  transmissions 
01 63  Slowest  “fast”  transmit  rate  (seconds) 

default  -  05  j6:  5  seconds  maximum  between  “fast”  transmissions 
0164  Synthesizer  stabilization  delay  (1.1  ms  steps) 

default  =  02] 6:  2.2  ms 

0165  Transmitter  stabilization  delay  (6.5  ps  loops) 

default  =  0F|  6:  100  ms 

0166  Maximum  time  receiver  is  powered  for  re -sync  (1 .1  ms  steps) 

default  =  20] 6:  35  ms 

0167  Maximum  space  between  AP  characters  to  keep  receiver  ON  (12  jus  loops) 

default  =  96|6:  L8  ms 

0168  Delay  from  AP  header  to  earliest  slot  request  (1.1ms  steps) 

default  =  18] 6:  20  ms 

0169  Delay  from  AP  request  to  transmit  response  in  BOD  (1.1  ms  steps) 

default  =  0Bj6:  12  ms 

016A  Default  processor  clock  start-up  interval  (69.4  ps  steps) 

default  =  80 16:  8.8  ms 

016B  Vcc  low  limit  (Vref  reading) 

default  =  C9i6:  201  =  3.0V  minimum 
016C  Vcc  high  limit  (Vref  reading) 

default  =  A7]6:  167  =  3.6V  maximum 

016D  Carbon  monoxide  control  loop  negative  saturation 

default  =  0F]6:  15  =  0.2  volts  minimum 
016E  Carbon  monoxide  control  loop  positive  saturation 

default  =  F0]6:  240  =  0.2  volts  below  Vcc 
01 6F  Photoelectric  smoke  detector  LED  drive  low 

default  =  2E|6:  46  =  0.6  volts 

0 1 70  Photoelectric  smoke  detector  LED  drive  high 

default  =  B1 16:  177  =  2.3  volts 

0171  Sensor  1  drive  voltage  low  (powers  all  low-power  sensors) 

default  =  F7,6:  247  =  lOOmV  below  Vcc 
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0172 

0173 

0174 

0175 

0176 

0177 

0178 


Sensor  2  drive  voltage  low  (powers  only  high-power  sensors) 
default  -  FBi6:  251  =  (50mV  below  Vcc 
Maximum  difference  between  thermistors  before  reading  is  ignored 
default  =  04]  6:  2*C 

Number  of  CO  =  8avg  before  indicate  stabilized 
default  =  32j6:  50  readings  must  match 
Number  of  02  =  8avg  before  indicate  stabilized 
default  =  64j  6:  100  readings  must  match 
Flooding  sensor  auto-bias  nominal  (used  at  startup) 
default  =  0A16:  10  =  0  inches 
Carbon  monoxide  nominal  (used  at  startup) 
default  =  0B is:  11  =5  ppm 
Oxygen  sensor  nominal 
default  =  D1 16:  209  -  20.9% 
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4. 1 .7  Environmental  Cluster  Sensor  Calibration 

Most  sensors  in  the  Environmental  Sensor  Cluster  must  be  calibrated  to  provide  sufficient 
accuracy.  Almost  all  environmental  sensors  are  calibrated  with  a  combination  of  scale 
factor  and  bias.  Scale  factor  varies  from  X  0.5  (hexadecimal  40)  to  X  1.99  (hexadecimal 
FF).  The  formula  for  scale  factor  is  X  =  N/128.  Bias  can  vary  +/-  127  from  zero.  Zero 
bias  is  hexadecimal  00.  FF  is  a  bias  of  —  1,  and  01  is  a  bias  of +1.  All  calibration 
coefficients  must  be  converted  to  hexadecimal  to  be  input  using  the  configuration 
monitor. 

While  it  is  possible  to  calibrate  the  sensors  manually  via  the  configuration  monitor,  a 
program  running  on  a  laptop  was  developed  to  aid  in  the  calibration  process  due  to  the 
number  of  Sensor  Clusters  that  would  need  to  be  calibrated.  The  laptop  program 
coordinates  calibration  of  all  the  sensors.  It  walks  the  operator  through  the  sensors  one  by 
one  and  calculates  the  calibration  coefficients  based  on  readings  at  specific  calibration 
points.  As  each  sensor  is  calibrated,  the  program  downloads  its  calibration  coefficients 
into  the  Sensor  Cluster  EEPROM.  The  calibration  program  logs  test  and  calibration 
readings  to  the  hard  drive  for  later  evaluation. 

The  laptop  calibration  program  offers  the  following  selections: 

A  -  Scan  ALL  sensors :  This  command  reads  all  the  sensors  and  presents  the  data  in 
engineering  units.  It  provides  a  quick  check  to  determine  how  well  the  Environmental 
Cluster  sensors  are  operating. 

S  -  Photoelectric  Smoke  Detector:  This  command  is  used  to  calibrate  the  photoelectric 
smoke  detector.  After  reading  the  ambient  value,  the  operator  will  be  asked  to  squeeze 
the  test  button  on  the  chamber  so  the  program  can  measure  the  “test”  value,  and  calculate 
the  scale  factor  and  bias  needed  for  calibration.  The  test  lever  arm  should  be  fully 
inserted  into  the  sensing  chamber  for  an  accurate  calibration. 

1  -  Ionization  Smoke  Detector:  This  command  is  used  to  calibrate  the  ionization  smoke 
detector.  While  similar  to  the  photoelectric  calibration,  the  test  value  is  electrically 
asserted,  and  no  operator  action  is  required. 

O  -  Oxygen  Sensor  @  20.9  %:  This  command  will  calibrate  the  oxygen  sensor  scale 
factor,  assuming  the  Environmental  Cluster  is  in  a  standard  atmospheric  environment 
with  a  20.9%  oxygen  level. 

P  -  Absolute  Pressure  at  14.7  psi:  This  command  will  calibrate  the  absolute  pressure 
sensor  scale  factor,  assuming  the  Environmental  Cluster  is  in  a  standard  atmospheric 
environment  with  a  pressure  of  14.7  psi.  The  ambient  pressure  sensors  installed  on 
several  of  the  Environmental  Clusters  did  not  perform  within  specifications,  and  could 
not  be  properly  calibrated. 
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F  -  Flooding  Sensor:  This  command  will  calibrate  the  flooding  sensor.  After  reading  the 
ambient  zero  flooding  level,  the  operator  will  be  asked  to  insert  the  detection  probe  a 
fixed  depth  into  a  container  of  water.  The  program  uses  the  two  values  to  calculate  scale 
factor  and  bias  to  calibrate  the  flooding  sensor. 

T  -  Calibrate  Temperature  sensors  at  ambient:  The  temperature  sensors  are  now  only 
calibrated  at  a  single  data  point.  For  ease  of  calibration,  this  is  done  at  ambient 
temperature.  This  single  reading  is  used  to  calculate  the  bias  required  for  the  active 
semiconductor  sensor,  and  to  adjust  the  family  of  curves  for  the  thermistors.  The  “V” 
command  is  provided  to  verify  the  temperature  sensors  are  properly  calibrated  over  the 
expected  habitation  temperature  range. 

C  -  Carbon  Monoxide  Sensor:  This  command  is  used  to  calibrate  the  carbon  monoxide 
sensor  in  a  chamber  where  it  can  be  subjected  to  known  concentrations  of  the  gas.  The 
early  Environmental  Clusters  were  calibrated  in  this  manner.  The  carbon  monoxide 
sensors  demonstrated  acceptable  accuracy  with  only  a  bias  adjustment,  and  not  all  units 
went  through  this  calibration  process. 

H  -  Humidity  Sensor:  This  command  is  used  to  calibrate  the  humidity  sensor  at  two 
points.  The  humidity  sensor  is  part  of  an  oscillator  circuit.  The  period  it  takes  the 
oscillator  to  make  a  fixed  number  of  cycles  is  measured  by  the  microcontroller.  Because 
the  nominal  value  of  the  humidity  sensor  can  vary  significantly,  the  calibration  process 
sets  not  only  the  scale  factor  and  bias,  but  also  sets  the  number  of  cycles  that  are 
measured  to  achieve  the  desired  resolution.  Humidity  calibration  of  the  first 
Environmental  Clusters  was  combined  with  the  temperature  calibration  verification. 
Results  from  that  calibration  process  were  disappointing.  The  humidity  sensors  may  have 
been  affected  by  the  temperature  changes,  perhaps  due  to  condensation  on  the  sensor 
during  the  low  temperature  portion  of  the  test.  The  humidity  sensor  bias  was  adjusted 
subsequent  to  calibration  so  the  sensors  would  read  the  correct  relative  humidity  at 
ambient.  It  may  be  worthwhile  investigating  an  alternate  calibration  to  achieve  better 
results. 

V  -  Verify  temperature  calibration  over  range:  After  the  temperature  sensors  are 
calibrated  at  ambient  temperature,  this  command  can  be  used  to  verify  the  calibration 
accuracy  at  two  points  in  a  thermal  test  chamber.  This  process  was  performed  on  the 
early  Environmental  Clusters,  and  the  single  point  calibration  of  the  temperature  sensors 
at  ambient  was  determined  to  be  sufficient. 

CTRL  C,  CTRL  H,  CTRL  V  -  Calibration  resets:  These  commands  can  be  used  to 
reset  the  carbon  monoxide,  humidity,  or  temperature  calibration  test  parameters  so  that 
calibration  cycle  can  be  repeated. 

L-  Lock  EEPROM  (select  Acquisition  Mode):  This  simple  command  sets  the 
LOCKED  bit  in  EEPROM,  and  prevents  the  upper  portion  of  EEPROM  from  being 
modified.  The  sensor  cluster  will  proceed  into  the  data  acquisition  mode,  and  try  to 
establish  communication  with  an  Access  Point  after  the  EEPROM  is  locked.  To  conserve 


61 


NSWCCD-TR-2003/02 


battery  power,  when  the  EEPROM  is  locked  the  cluster  should  be  switched  off  unless  it  is 
near  a  functioning  Access  Point. 

U  -  Unlock  EEPROM  (select  Monitor  Mode):  This  simple  command  clears  the 
LOCKED  bit  in  EEPROM,  and  enables  the  calibration  coefficients  and  system 
parameters  in  the  upper  portion  of  EEPROM  to  be  altered.  The  sensor  cluster  will  power 
up  in  the  monitor  mode  whenever  the  EEPROM  is  unlocked. 

X-  Exit:  This  command  terminates  the  calibration  program. 
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4.1.8  Structural  Cluster  Configuration  Monitor 

A  simple  interactive  monitor  offers  test  modes  useful  for  calibration,  and  allows 
calibration  coefficients  and  system  constants  to  be  altered.  The  monitor  is  automatically 
entered  at  power-up  when  the  EEPROM  is  unlocked.  At  a  minimum,  the  Sensor  Cluster 
serial  number  must  be  entered,  and  the  protected  portion  of  the  EEPROM  locked.  After 
the  EEPROM  is  locked,  it  is  still  possible  to  for  the  Sensor  Cluster  to  enter  the  monitor. 
When  power  is  cycled,  the  Sensor  Cluster  will  issue  the  prompt  “RSVP”  over  its  serial 
port  at  19.2K  baud  with  the  radio  off  If  the  Sensor  Cluster  receives  a  space  character 
within  2  seconds  of  the  prompt,  and  “RSVP”  within  the  next  10  seconds,  then  it  will  enter 
the  monitor  mode.  If  anything  other  than  the  space  character  is  received  within  the  first 
two  seconds,  or  anything  other  than  “RSVP”  is  received  within  the  next  10  seconds,  the 
Sensor  Cluster  transmits  “END”  and  enters  its  operational  mode.  The  Sensor  Cluster  does 
not  check  for  entry  into  the  monitor  mode  again  unless  power  is  removed  for  several 
seconds. 

The  following  commands  are  available  in  monitor  mode: 

?  Sensor  Query  -  outputs  standard  structural  message  data  in  ASCII  format 

!  Monitor  the  shock  sensors  -  outputs  shock  event  message  data  in  ASCII  format  (hit  a  key  to  exit) 

-  Read  and  display  Sarcos  strain  sensors 
A  Turn  sensor  power  ON 

_  Turn  sensor  power  OFF 

Q  Query  selected  sensor  while  EEPROM  calibration  data  is  displayed 

Ctrl  S  Scan  A/D  and  output  raw  readings  contained  in  the  A/D  buffer  (used  only  during  development) 
Ctrl  L  Lock  EEPROM 

Ctrl  1)  Unlock  EEPROM  (requires  **Y”  acknowledgement  before  the  unlock  is  performed) 

Ctrl  Z  Exit  Monitor  (also  insures  EEPROM  is  locked) 

Calibration  data  in  locked  EEPROM  may  be  entered  or  modified  using  the  following 
commands: 


# 

@ 

T 

1 

2 

3 

4 

5 

6 
L 
K 


4-byte  factory  serial  number 

PSM  channel  assignments  (default  are  1  and  81) 

linear  temperature  sensor  (scale  factor  and  bias)  “Q”  reads  raw  &  calibrated  temperature 

navigation  accelerometer  #1  (scale  factor  and  bias)  "Q”  reads  raw,  cal,  max,  min,  8avg,  p-p 

navigation  accelerometer  #2  (scale  factor  and  bias)  “Q”  reads  raw,  cal,  max,  min,  8a vg,  p-p 

shock  accelerometer  (scale  factor  and  bias)  t4Q”  reads  raw,  cal,  256avg 

Sarcos  strain  gauge  #1  (16-bit  bias)  “Q”  reads  16-bit  raw  &  bias  adjusted 

Sarcos  strain  gauge  #2  (16-bit  bias)  "Q”  reads  1 6-bit  raw  &  bias  adjusted 

Sarcos  scale  factor  adjustment  (8 -bit  gain  shift) 

6  bytes  for  physical  location  parameters  (optional) 
provides  access  to  all  system  constants  that  can  be  modified 


Thresholds  and  operational  parameters  in  unlocked  EEPROM  may  be  entered  or 
modified  using  the  following  commands: 

•  configuration  flags  (selects  which  oxygen  sensors  are  enabled) 

%  threshold  limits  for  all  sensors 

Z  sleep  interval  after  AP  search  fails  in  32-second  increments 
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Only  the  thresholds  and  operational  parameters  can  be  modified  via  the  AP. 

EEPROM  data  is  entered  via  hexadecimal  characters.  Data  can  be  edited  using  TAB  to 
skip  fields,  and  BACKSPACE  to  correct  entries.  Editing  the  displayed  set  of  EEPROM 
parameters  is  terminated  with  the  ENTER  key.  The  data  displayed  is  written  to  EEPROM 
at  that  time.  Only  valid  hexadecimal  characters  will  be  accepted  with  one  exception.  If 
“Q”  is  entered  immediately  after  sensor  calibration  data  is  displayed  (with  cursor  still  at 
the  beginning  of  the  line),  that  sensor  will  be  sampled,  and  the  raw  and  calibrated 
readings  for  it  will  be  displayed.  This  function  is  useful  during  test  and  calibration  of  the 
sensors. 

Structural  Cluster  Standard  Data  Message 


3C  Message  Type  for  Standard  Data  Message 

XX  LS  Byte  of  32 -bit  cluster  ID  number 

XX  Alert  Status  byte 

bit  7  (80i6)  “  strain  gauge  #1  >  positive  threshold 
bit  6  (40i6)  =  strain  gauge  #1  <  negative  threshold 
bit  5  (20l6>  =  strain  gauge  #1  >  positive  threshold 
bit  4  (10l6)  =  strain  gauge  #1  <  negative  threshold 
bit  3  (08i6)  =  high  navigation  accelerometer  #1 
bit  2  (0416)  =  high  navigation  accelerometer  #2 
bit  1  (0216)  =  high  shock  accelerometer 
bit  0  (01 16)  =  low  primary  battery  alert 
XX  Health  Status  byte 

bit  7  (80i6)  =  low/high  power  supply  voltage 
bit  6  (40i6)=:not  used 

bit  5  (20i6)  =  linear  temperature  above  high  threshold 
bit  4  (10j6)  -  linear  temperature  below  low  threshold 
bit  3  (0S16)  =  RF  signal  strength  below  low  threshold 
bit  2  (04)6)  =  sensor  power  low  voltage 
bit  1  (02l6)  -  sensor  1  on  low  voltage 
bit  0  (01)6)  =  not  used 
XX  Battery  Input  (from  PMM) 

XX  Linear  Temp  Sensor  Level 

XXXX  SARCOS  strain  gauge  #1  positive  max  (16  bits) 
XXXX  SARCOS  strain  gauge  #1  negative  max  (16  bits) 
XXXX  SARCOS  strain  gauge  #2  positive  max  (16  bits) 
XXXX  SARCOS  strain  gauge  #2  negative  max  (16  bits) 

XX  Navigation  accelerometer  #1  8-sample  p-p  average 

XX  Navigation  accelerometer  #1  PP  amplitude 

XX  Navigation  accelerometer  #1  Vi  cycle  time 

XX  Navigation  accelerometer  #2  8-sample  p-p  average 

XX  Navigation  accelerometer  #2  PP  amplitude 

XX  Navigation  accelerometer  #2  Vi  cycle  time 

XX  RSSI  (received  signal  strength  indicator) 

XX  2X  reference  voltage  (diagnostic) 

XX  Switched  sensor  power  “ON”  voltage  (diagnostic) 

XX  Sync  quality  status  (diagnostic) 

XX  Oscillator  start-up  delay  (diagnostic) 

XXXX  16-bit  CRC 

CRLF  (Appended  only  in  Monitor  Mode) 


V  =  3.3  x  (reading  /  128) 
deg  C  =  (reading  -  40)  /  2 
scale  factor  depends  on  gain 
scale  factor  depends  on  gain 
scale  factor  depends  on  gain 
scale  factor  depends  on  gain 
G  p-p  -  reading  /  50 

G  p-p  =  reading  /  50 
duration  in  seconds  =  reading 
G  p-p  =  reading  /  50 
G  p-p  =  reading  /  50 
duration  in  seconds  =  reading 

V  =  3.3  x  (reading  /  256) 
(used  to  calculate  actual  Vcc) 

V  =  3.3  x  (reading  /  256) 
unitless  quantity 

time  =  (reading  x  138  ps) 
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4.1. 8.1  Structural  Cluster  Shock  Event  Message 

3D  Message  Type  for  Shock  Event 

XX  LS  Byte  of  32  -bit  cluster  ID  number 
XX  Alert  Status  byte 

bit  7  (SOie)^  strain  gauge  #1  >  positive  threshold 
bit  6  (40i6)  -  strain  gauge  #1  <  negative  threshold 
bit  5  (20i6)  =  strain  gauge  #1  >  positive  threshold 
bit  4  (10i6)  =  strain  gauge  #1  <  negative  threshold 
bit  3  (0816)  =  high  navigation  accelerometer#! 
bit  2  (04ie)  =  high  navigation  accelerometer  #2 
bit  1  (02i6)  =  high  shock  accelerometer 
bit  0  (01  ie)  =  low  primary  battery  alert 
XX  Health  Status  byte 

bit  7  (80i  e)  -  low/high  power  supply  voltage 
bit  6  (4016)  =  not  used 

bit  5  (20)  e)  =  linear  temperature  above  high  threshold 
bit  4  ( 1  Oj  e) =  linear  temperature  below  low  threshold 
bit  3  (08je)  =  RF  signal  strength  below  low  threshold 
bit  2  (04l6)  =  sensor  power  low  voltage 
bit  1  (02j6)  =  sensor  1  on  low  voltage 
bit  0  (0116)  =  not  used 


XX 

Battery  Input  (from  PMM) 

V  =  3.3  x  (reading  /  128) 

XX 

Linear  Temp  Sensor  Level 

deg  C  =  (reading  -  40)  /  2 

XX 

Shock  sensor  256-sample  average 

G  average  =  reading  -  125 

XX 

Shock  sensor  first  half-cycle  peak 

G  peak  =  reading  -  125 

XX 

Shock  sensor  first  half-cycle  duration 

ms  =  approximately  reading  /  5 

XX 

Shock  sensor  second  half-cycle  peak 

G  peak  =  reading  -  125 

XX 

Shock  sensor  second  half-cycle  duration 

ms  =  approximately  reading  /  5 

XXXX  16-bit  CRC 

CRLF  (Appended  only  in  Monitor  Mode) 


4.1. 8.2  Structural  Cluster  EEPROM  Calibration  Data 

NOTE:  The  first  3 1  bytes  cannot  be  locked,  and  can  be  modified  by  the  AP. 

STRUCTURAL  CLUSTER  CONTROL  (Modifiable  by  the  AP) 

Address  Access  Parameter  (default  values  are  in  hexadecimal) 

+  Configuration  Flags 

0101  First  byte  of  configurations  flags 

bit  7  (80H)  =  enable  respond  to  data  request  in  any  BOD 
other  bits  not  used 

default  =  00H:  disable  response  in  any  BOD 
0102  Second  byte  of  configurations  flags  (not  used) 

default  =  00H 

0103  Z  Sleep  interval  if  AP  search  fails  (N  x  32  sec) 

default  =  02H:  64  seconds 
X  Transmit  parameters 

4  spare  bytes 
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4.L8.2.1  Structural  Cluster  Alert  Thresholds  (Modifiable  By  The  AP) 

Address  Access  Parameter  (default  values  are  in  hexadecimal) 

%  Threshold  parameters 

0108  Linear  temperature  sensor  low  threshold 

default  =  3C,6:  10  degrees  C  (#  =  40  +  2*C) 

0 1 09  Linear  temperature  sensor  high  threshold 

default  =  78i6’  40  degrees  C  (#  =  40  +  2*C) 

010A  Sarcos  strain  gauge  #1  positive  fast-sample  threshold  (avg.  peak) 

default  =  8A!6:  +307  pstrain  (LSB  -  30.72  @  gain  shift  =  1) 
010B  Sarcos  strain  gauge  #1  negative  fast  sample  threshold  (avg.  peak) 

default  =  76i6:  -307  pstrain  (LSB  =  30.72  @  gain  shift  =  1) 

010C  Sarcos  strain  gauge  #1  positive  ALERT  threshold  (peak) 

default  =  A016:  +1000  pstrain  (LSB  =  30.72  @  gain  shift  =  1) 
010D  Sarcos  strain  gauge  #1  negative  ALERT  threshold  (peak) 

default  =  60l6:  -1000  pstrain  (LSB  =  30.72  @  gain  shift  =  1) 
010E  Sarcos  strain  gauge  #2  positive  fast-sample  threshold  (avg.  peak) 

default  =  8Ai6:  +307  pstrain  (LSB  =  30.72  @  gain  shift  =  1) 
010F  Sarcos  strain  gauge  #2  negative  fast  sample  threshold  (avg.  peak) 

default  =  76i6:  -307  pstrain  (LSB  =  30.72  @  gain  shift  =  1) 

0110  Sarcos  strain  gauge  #2  positive  ALERT  threshold  (peak) 

default  =  A0]6:  +1000  pstrain  (LSB  =  30.72  @  gain  shift  =  1) 
0111  Sarcos  strain  gauge  #2  negative  ALERT  threshold  (peak) 

default  =  60i6:  -1000  pstrain  (LSB  =  30.72  @  gain  shift  =  1) 
0112  Nav.  accelerometer  #1  fast-transmit  threshold  (peak-to-peak) 

default  =  14i6:  0.4G  peak-to-peak  (at  50  counts  per  G) 

01 13  Nav.  accelerometer  #1  ALERT  threshold  (peak-to-peak) 

default  =  32j6:  LOG  peak-to-peak  (at  50  counts  per  G) 

0114  Nav.  accelerometer  #2  fast-transmit  threshold  (peak-to-peak) 

default  =  14i6i  0.4G  peak-to-peak  (at  50  counts  per  G) 

0115  Nav.  accelerometer  #2  ALERT  threshold  (peak-to-peak) 

default  =  32] 6:  1.0G  peak-to-peak  (at  50  counts  per  G) 

0116  Shock  accelerometer  zero  band  threshold  (delta  from  average) 

default  =  05 j6:  +/-  5G  (at  1  count  per  G) 

0117  Shock  accelerometer  ALERT  threshold,  (delta  from  average) 

default  =  14j6:  +/  20G  peak  (at  1  count  per  G) 

0118  Battery  #1  low  ALERT  threshold  (01  for  no  ALERT) 

default  =  9816:  3.9V  (#  -  39*V) 

0119  RF  signal  strength  low  threshold 

default  =  80i  6i  half  scale  (#  =  77*V) 

01 1 A  -  01  IF  Spare  bytes  in  unlocked  region 

default  =  all  zero 
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4.1. 8.2.2  Structural  Cluster  Locked  Calibration  Coefficients 
Address  Access  Parameter  (default  values  are  in  hexadecimal) 


0120 
0124 
01 2A 
01 2C 
01 2E 
0130 
0132 
0133 
0135 
0137 


#  Sensor  Cluster  4 -byte  serial  number 

default  =  5 253 5650 ig  before  actual  cluster  S/N  is  programmed 
L  Sensor  Cluster  6-byte  physical  location  reference 

default  =  all  bytes  cleared  (not  used) 

@  PSM  channel  numbers  -  can  be  changed  if  required  due  to  interference 
default  =  0116?  51!6:  Primary  PSM  #1,  Secondary  PSM  #81 
T  Linear  temperature  sensor  calibration  scale  factor  &  bias 

default  =  76i6j  1516;  (gain  X  0,92,  +21  bias)  0O.25V,  10OO3.O5V 

1  Navigation  accelerometer  #1  scale  factor  &  bias 

default  =  80]  e,  00]g:  (gain  X  1.0,  zero  bias) 

2  Navigation  accelerometer  #2  scale  factor  &  bias 

default  =  80]  6}  00] 6:  (gain  X  L0,  zero  bias) 

3  Shock  accelerometer  bias 

default  =  00jg:  zero  bias 

4  Sarcos  strain  gauge  #1  1 6-bit  bias  (adjust  nominal  reading  to  8000  hex) 

default  =  00] g,  00] g:  zero  bias 

5  Sarcos  strain  gauge  #2  16 -bit  bias  (adjust  nominal  reading  to  8000  hex) 

default  =  00]  g,  00)  6:  zero  bias 

6  Sarcos  scale  adjustment  shifts  N  bits  from  LSB  to  MSB  in  IS-bit  data  word 

default  =  01 16:  15,.,„..,..,..1+P  default  =  bits  14-7  (LSB  =  30.72) 
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4.1. 8.2.3  Structural  Cluster  Locked  System  Constants 

Address  Access  Parameter  (default  values  are  in  hexadecimal) 

K  System  Constants  -  all  system  constants  are  accessed  as  one  string 
0138  Control  flags 

bit  7  (8016)  =  select  transmit  data  in  ASCII  mode 
bit  6  (40!6)  =  no  CRC  check  on  received  data 
all  other  bits  not  used 
default  =  00i6:  no  options  selected 

0139  Number  of  re -sync  tries  before  moving  to  next  AP 

default  =  04|6:  three  tries  (tries  =  N-l) 

01 3A  Number  of  re -sync  cycles  before  “aging”  frequency  table 

default  =  09)6:  wait  for  9  successful  re -sync  cycles 
0 1 3B  Synthesizer  stabilization  delay  ( 1 . 1  -ms  steps) 

default  =  02 j 6:  2.2  ms 

013C  Transmitter  stabilization  delay  (6.5-ps  loops) 

default  =  OF^:  100  ms 

013D  Maximum  time  receiver  is  powered  for  re -sync  (1 .1  -ms  steps) 

default  =  2016:  35  ms 

013E  Maximum  space  between  AP  characters  to  keep  receiver  ON  (12-ps  loops) 

default  -  96] 6:  1.8  ms 

013F  Delay  from  AP  header  to  earliest  sbt  request  (1 . 1-ms  steps) 

default  =  18!6:  20  ms 

0140  Delay  from  AP  request  to  transmit  response  in  BOD  ( 1 . 1-ms  steps) 

default  =  0B16:  12  ms 

0141  Default  processor  clock  start-up  interval  (69.4-ps  steps) 

default  =  80] 6:  8.8  ms 

0 1 42  General  Quarters  mode  start  -up  delay  (1.1  -ms  steps) 

default  =  07!6:  7.7  ms  (simulates  normal  clock  start-up  interval) 

0143  Vcc  low  limit  (Vref  reading) 

default  =  C9j6:  201  =  3.0V  minimum 

0144  Vcc  high  limit  (Vref  reading) 

default  -  A7j6:  167  =  3.6V  maximum 

0145  Sensor  1  drive  voltage  low  (powers  all  low-power  sensors) 

default  =  F7]6:  247  =  (lOOmV  below  Vcc) 

0146  Sensor  2  drive  voltage  low  (powers  only  high-power  sensors) 

default  -  FBl6:  251  =  (50mV  below  Vcc) 

A  description  of  the  major  electrical  and  functional  characteristics  of  the  RSVP 
Environmental  Sensor  Cluster  and  Structural  Sensor  Cluster  (ESC  and  SSC)  can  be  found 
in  the  RSVP  Systems  Engineering  Study  [ref  4]  .  The  Environmental  Sensor  Cluster  is 
designed  to  monitor  a  set  of  parameters  to  determine  whether  a  fire  or  flooding  condition 
exists  in  a  ship  compartment.  Included  are  redundant  temperature  sensors,  both 
photoelectric  and  ionization  smoke  sensors,  and  sensors  that  monitor  carbon  monoxide, 
oxygen,  and  humidity  levels.  A  differential  pressure  sensor  can  measure  flooding  using 
an  external  probe.  An  external  input  is  also  available  for  a  hatch-position  indicator.  The 
Structural  Sensor  Cluster  provides  external  interfaces  for  two  navigation  accelerometers, 
a  shock  accelerometer,  and  two  SARCOS  strain  sensors.  The  Structural  Sensor  Cluster 
samples  these  sensors  periodically,  and  adjusts  its  sample  rate  as  warranted  by  sea 
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conditions.  The  shock  sensor  is  only  monitored  in  General  Quarters  mode  to  conserve 
power. 

Data  from  both  the  Environmental  and  Structural  Sensor  Clusters  are  periodically 
transmitted  to  an  Access  Point  (AP)  in  the  compartment,  which  combines  that  data  with 
data  received  from  other  clusters  and  forwards  it  on  to  a  monitoring  station.  Alert 
conditions  are  also  sent  to  the  Access  Point  whenever  a  sensor  reading  exceeds  a 
predetermined  threshold.  The  Access  Point  can  change  thresholds  and  sample  rates  to 
select  an  optimum  tradeoff  between  data  granularity  and  power  consumption. 

The  Environmental  and  the  Structural  Sensor  Clusters  share  the  same  circuit  board 
design.  Portions  of  the  circuit  board  are  populated  differently,  a  function  of  which  cluster 
is  being  assembled.  A  completed  cluster  assembly  includes  the  environmental  or 
structural  circuit  board,  a  power  module  containing  a  battery  pack  and  regulators,  and  a 
radio  module  that  provides  the  RF  link  to  the  Access  Point. 
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4.1.9  Power  Management  Module  (PMM) 

The  RSVP  power  module  supplies  regulated  power  to  an  RSVP  environment  or  structural 
sensor  cluster.  The  power  is  supplied  from  a  capacitor  that  is  charged  with  power 
scavenged  from  the  environment  or  from  a  battery  if  there  is  insufficient  scavenged 
power.  The  sources  of  scavenged  power  can  be  photovoltaics,  thermoelectric,  vibration- 
to-electric  or  any  others  that  can  supply  charge  to  a  capacitor.  The  specific  design  and 
implementation  of  the  RSVP  power  module  is  based  mainly  on  the  use  of  photovoltaics, 
due  to  the  lack  of  specific  information  on  other  techniques  for  scavenging  power.  A 
primary  (non-rechargeable)  battery  is  used  for  startup  and  as  a  backup  to  the  scavenged 
power  sources. 

4.1.9.1  Requirements  and  Goals 

The  requirements  for  the  RSVP  power  module  are  listed  in  Table  8.  We  define  a 
specification  (Spec)  as  an  RSVP  requirement  that  must  be  met,  and  a  goal  as  a 
requirement  that  the  RSVP  program  would  like  to  meet.  Acceptable  performance  may  not 
require  meeting  all  goals.  For  example,  lower  efficiency  may  be  acceptable  depending 
upon  solar  cell  performance  and  load  requirements. 


Table  8  Specifications  and  Goals  for  the  RSVP  Power  Module. 


Requirement 

Values 

Conditions 

Description  /  Comments 

mm® 

E5M 

Nominal  Output 
Voltage  (primary) 

3.3  Vdc 

lout  less  than 

maximum 

values 

Voltage  supplied  to  RSVP 
module 

Spec 

Nominal  Output 
Voltage  (secondary 

9  Vdc 

to  be 

determined 

Voltage  for  some  sensors 

Spec 

Output  Voltage 
Limits,  primary 
output 

3.45  V  max 
3.15  V  min 

1mA  <  lout  < 
100mA 

Nominal  output  +1-5% 

Spec 

Average  Output 
Current 
primary  output 

0.33  mA 
min 

Average  current  supplied 
to  RSVP  module  excluding 
power  module  self¬ 
consumption 

Spec 

Maximum  Output 
Current  (primary) 

100mA 

Peak  current  supplied  to 
RSVP  module 

Spec 

Load  Regulation, 
primary  output 

100  mV 

10mA  <  lout  < 
100mA 

Load  regulation  specifies 
how  much  the  output 
changes  voltage  when  the 
load  current  changes. 

Spec 

5  mV 

lout  <  10  mA 

Average  Output 
Power 

2  mW 

Average  power  delivery 
capability  of  power  module 
electronics.  Assumes 

Goal 
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sufficient  power  available 
from  PV  source. 

Efficiency 

>50% 

nominal  output 
power  level 

Power  out  /  power  in  from 
PV  source. 

Goal 

Supply  current 

30 

microamps 

average 

Current  required  for 
operation  of  power 
module.  Does  not  include 
current  supplied  to  load. 

H 

Lifetime 

5  years  min. 

Time  of  operation  and/or 
storage  without  replacing 
battery,  etc. 

Goal 

Scavenged  Energy 
Storage 

0.1  Joule 
minimum 

This  determines  how  long 
the  power  module  can 
supply  the  load  without 
energy  input. 

T=  energy  /  power  out.  For 
a  lmW  load,  this  capacity 

Is  100  s. 

Goal 

Primary  Battery 
Capacity  for  180 
day  Demonstration 

4  Amphour 

300  microamp 
load,  180  days 

For  180  day  demonstration 
assuming  worst  case  of  no 
scavenged  power  and 
factor  of  3  safety  margin. 

Goal 

Primary  Battery 
Voltage 

5.5V  >  Vbat 
>  3.6V 

Operational 
lifetime,  lout  < 
100mA 

Maximum  is  determined  by 
ASIC  maximum  logic 
voltage,  minimum  is  set  by 
linear  regulator  dropout. 

Spec 

Monitoring 

capabilities 

Includes  provisions  for 
external  monitoring  of  the 
battery  and  output  voltages 

Spec 

4.1.9.2  Power  Module  Description 

Figure  10  shows  a  simplified  block  diagram  of  the  power  module.  In  power  scavenging 
mode,  the  photovoltaic  array  and  thermoelectric  and  vibration-to-electric  power  sources 
deliver  power  to  the  power  module  ASIC.  The  energy  from  the  sources  will  be 
temporarily  held  .on  input  storage  capacitors.  The  power  module  ASIC  converts  dc  power 
from  the  input  storage  capacitors  and  delivers  it  to  the  main  energy  storage  capacitor. 
Power  from  the  main  storage  capacitor  is  regulated  and  delivered  to  the  loads.  A  voltage 
regulator  is  used  to  control  the  voltage  (3.3V)  supplied  to  the  primary  load,  and  a  step-up 
regulator  is  used  to  produce  the  secondary  (9V  or  other)  output.  The  power  module  ASIC 
monitors  the  voltage  of  the  primary  battery,  the  primary  output  and  the  storage 
capacitors.  This  information  is  used  to  help  regulate  the  primary  output  voltage  and  is 
supplied  to  the  RSVP  processor  module  as  analog  levels  at  the  request  of  the  processor. 
For  startup,  the  power  module  ASIC  will  draw  power  from  a  primary  battery  and  use  this 
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source  instead  of  the  main  energy  storage  element  until  it  senses  that  sufficient  energy 
has  been  stored  to  allow  changeover  to  scavenged  power  mode. 


Figure  10  Power  Module  Block  Diagram 


Although  the  load  presented  to  the  RSVP  power  module  requires  a  very  low  average 
power,  the  instantaneous  current  required  can  vary  from  16  microamperes  to  100  mA. 
Furthermore,  in  some  infrequent  circumstances,  the  power  module  may  need  to  supply  70 
mA  for  as  much  as  20  seconds. 

It  is  possible  that  the  scavenged  power  sources  will  provide  sufficient  power  to  meet  the 
average  power  needs.  The  main  energy  storage  element  (capacitor)  has  sufficient  capacity 
to  deliver  the  maximum  currents,  but  only  for  short  periods  (milliseconds).  This  should 
be  sufficient  for  normal  operation,  but  not  for  the  frequency  scanning  operation  (70mA 
and  20s).  In  that  infrequent  circumstance,  the  power  module  will  switch  back  to  the 
primary  battery. 

Figure  1 1  shows  a  more  detailed  diagram  of  the  power  module.  The  various  elements  are 
described  in  greater  detail  in  the  following  subsections.  Most  of  the  elements  are  part  of 
the  power  module  ASIC.  External  elements  include  the  PV  module,  the  alternate  power 
sources,  blocking  diodes,  storage  capacitors,  the  oscillator  and  the  step-up  regulator. 
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Figure  11  Detailed  Diagram  Of  Power  Module 


4. 1.9.3  Photovoltaic  Module,  Blocking  Diode  &  Charge-Storage  Capacitor 

The  photovoltaic  module  supplies  current  that  ultimately  is  used  to  recharge  the  main 
energy  storage  element.  Because  of  the  expected  variations  in  light  levels,  the  output 
voltage  of  the  PV  module  will  vary  over  perhaps  a  two-to-one  range.  This  voltage  will 
also  depend  on  the  PV  type  (crystalline,  amorphous,  etc.).  Evaluation  of  several 
photocells  led  to  the  conclusion  that  a  standard  PV  module  having  a  nominal  output  of 
12-Vdc  in  direct  sunlight  can  produce  dc  levels  of  approximately  4  to  6V  in  the 
compartment  lighting.  This  voltage  level  is  then  stepped  down  to  that  of  the  main  energy 
storage  element. 

For  the  power  management  module  prototype,  a  photovoltaic  module  was  constructed 
from  a  number  of  silicon  photodiodes  that  had  been  developed  for  a  PV  efficiency  study. 
Each  diode  was  2  cm  by  2  cm  and  16  were  connected  in  series  to  make  a  sub -module. 
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The  module  was  made  by  connecting  3  sub -modules  in  parallel.  Figure  12  is  a 
photograph  of  the  photovoltaic  module,  and  Figure  13  is  a  graph  of  the  I-V  characteristic 
of  the  module  for  fluorescent  illumination  in  a  typical  laboratory  setting.  With  this 
illumination,  the  PV  module  can  supply  the  level  of  power  needed  for  the  sensor  cluster 
(approximately  1  mW.)  Light  levels  on  a  ship  are  expected  to  be  lower. 


Figure  12  Prototype  Photovoltaic  Module. 


A  blocking  diode  is  required  to  keep  the  PV  module  from  discharging  the  storage 
capacitor  in  a  no- light  situation.  The  forward  voltage  of  the  diode  (when  conducting) 
represents  a  loss  of  energy,  so  a  diode  (10BQ015)  with  a  low  forward  voltage  was 
chosen. 

The  storage  capacitor  collects  charge  from  scavenging  sources  and  supplies  it  through  the 
power  module  ASIC  to  the  load.  Since  the  amount  of  power  required  by  the  load  may  at 
times  be  much  greater  than  that  supplied  by  the  scavenging  sources,  the  storage  capacitor 
must  have  sufficient  capacity  so  large  amounts  of  power  may  be  supplied  to  the  load  for 
short  periods.  For  example,  the  load  may  require  on  the  order  of  3.3  V  times  100mA  for  1 
ms,  and  during  such  an  event,  the  capacitor  discharges  much  faster  than  it  is  being 
charged,  so  its  terminal  voltage  falls.  Of  course,  the  larger  the  value  of  capacitance,  the 
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bwer  the  loss  of  voltage.  Unfortunately,  a  larger  capacitance  is  also  physically  larger  and 
has  greater  leakage  current  (which  represents  a  loss  of  energy.)  Ultimately,  conventional 
low-  leakage  electrolytic  capacitors  (10,000  uF,  Panasonic  part  number  ECA1CH103) 
were  chosen  for  the  charge  storage  capacitor. 

If  the  PV  module  is  exposed  to  direct  sunlight,  its  power  output  can  be  as  much  as  1000 
time  the  amount  expected  during  shipboard  operation.  In  this  case,  the  PV  module  output 
may  be  a  higher  voltage  (possibly  20V)  than  the  power  module  ASIC  is  capable  of 
handling  (12V).  A  limiting  circuit  such  as  a  Zener  diode  or  a  crowbar  circuit  using  a 
thyristor  should  be  included  to  protect  the  ASIC.  The  Zener  circuit  would  need  to  limit 
the  voltage  to  the  power  module  ASIC  to  approximately  10  V.  A  crowbar  circuit  would 
clamp  the  PV  module  output  to  approximately  zero  volts  until  the  PV  array  was  placed  in 
the  dark.  Either  circuit  would  be  external  to  the  ASIC  and  draw  negligible  power  under 
normal  operating  conditions. 
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Figure  13  Prototype  Photovoltaic  Module  I-V  Characteristic. 

A  clamp  circuit  was  developed  to  magnify  the  power  dissipation  capability  of  a  low- 
power  Zener  diode.  This  circuit  is  shown  in  Figure  14.  It  uses  two  small  signal  bipolar 
transistors  to  amplification  of  the  diode  current  and  a  low-cost  power  MOSFET  to 
provide  power  dissipation. 
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Figure  14  PV  Clamp  Diagram 


The  performance  of  this  circuit  is  quite  good.  The  nominal  clamping  voltage  is  8.6  V 
(this  could  be  adjusted  up  or  down  by  choosing  a  different  zener  diode.)  At  input  voltages 
less  than  8.43  V  input,  the  circuit  draws  no  more  than  10  microamps,  and  as  shown  in 
Figure  15,  the  clamp  characteristic  is  very  abrupt. 
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Figure  15  PV  Limiter  Clamping  Behavior. 
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4.1.9.4  Alternate  power  sources 

Alternate  power  sources  are  handled  in  much  the  same  way  as  the  PV  module.  Charge 
from  the  power  sources  is  accumulated  on  a  capacitor.  When  the  voltage  reaches  a 
sufficient  level,  the  dc-to-dc  converter  would  be  turned  on  to  transfer  the  accumulated 
energy  to  the  main  energy  storage  element.  This  process  would  continue  until  the  voltage 
decreased  to  a  lower  limit  determined  by  the  capability  of  the  dc-to-dc  converter.  The 
power  module  monitors  the  several  sources  and  intelligently  switches  between  them. 

4. 1.9.5  Source  input  requirements 

Figure  16  shows  a  model  of  the  input  impedance  seen  by  an  alternate  power  source  and 
by  the  PV  module.  The  input  to  the  PMM  can  be  modeled  using  a  diode,  a  capacitor  and 
a  resistor.  Current  from  the  source  flows  through  the  diode  into  the  parallel  combination 
of  the  capacitor  and  resistor.  The  resistance  is  a  function  of  the  current  of  the  load  and  the 
frequency  of  the  switching  between  sources  (should  more  than  one  source  be  active.) 
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Figure  16  PMM  Input  Model  Seen  By  Power  Source. 


The  ASIC  architecture  limits  the  range  of  power  source  currents  and  voltages  that  are 
acceptable.  These  limits  are  outlined  in  Table  9. 


Table  9  Source  Requirements  and  PMM  Input  Characteristics. 


Requirement 

Value 

Conditions 

Description/Comment 

Input  Voltage, 

source 

operating 

8.5  V 
maximum 

4.5  V  minimum 

Source  supplying 
power  to  PMM 

Input  Voltage, 
source  not 
operating 

8.5V 

maximum, 

0  V  minimum 

Source  not 
supplying  power  to 
PMM 

if  the  input  voltage  exceeds 
4.5  volts,  the  PMM  may 
draw  current  from  that 
input 

Input  Current, 
maximum 

10  mA 

average 

actual  current  will  depend 
upon  loads,  may  not 
exceed  this  average  value 
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Input  Current, 
maximum  peak 

1  A 

instantaneous  peak 

average  value  must  not  be 
exceeded 

Input  Current, 
minimum 

0 

may  not  be  negative 

PMM  Input 
Capacitance 

10,000 

microFarads 

nominal 

PMM  Input 
Resistance 

minimum 

7kohm  @  10 
mA 

maximum 
200kohm  @0.3 
mA 

PMM  drawing 
power  from  power 
source 

depends  on  load  current 

4.1.9.6  Primary  Battery 

The  primary  battery  used  for  the  prototype  PMM  consists  of  three  alkaline  AA  cells.  This 
results  in  a  nominal  terminal  voltage  of  4.5  V  and  a  capacity  of  approximately  2 
amphours.  This  is  more  than  sufficient  for  a  180-day  demonstration  of  a  sensor  cluster. 

Other  primary  battery  types  could  be  used  with  the  PMM.  The  maximum  battery  voltage 
allowable  is  5.5  V  (this  is  dictated  by  the  maximum  supply  voltage  of  the  power  module 
ASIC),  and  the  minimum  battery  voltage  is  3.6V  (this  is  dictated  by  the  operation  of  the 
power  module  ASIC  power  source  switch  and  linear  regulator).  For  use  with  the  RSVP 
sensor  cluster,  the  battery  should  also  be  able  to  source  up  to  70  mA  with  a  terminal 
voltage  of  at  least  3.6  V. 

4.1.9.7  Oscillator 

An  oscillator  is  used  develop  the  clocks  required  for  the  dc-to-dc  converters  and  for  the 
state  machine  that  controls  the  operation  of  the  power  module  ASIC.  A  32.7-kHz,  low- 
powered  oscillator  (ECS  number  ECS-327SMO)  was  chosen  for  use  in  the  power 
management  module.  This  oscillator  is  very  small  and  requires  approximately  10 
microamperes  for  operation.  The  oscillator  draws  unregulated  power  from'  the'  power 
switch  output  of  power  module  ASIC. 

4.1 .9.8  Power  Module  ASIC 

The  power  module  ASIC  has  a  number  of  functions.  It  monitors  the  voltage  of  the 
various  energy  storage  elements.  Based  on  these  voltages,  it  transfers  energy  from  the 
sources  to  the  main  energy  storage  element  and  chooses  between  the  main  energy  storage 
element  and  the  primary  battery  to  supply  power  to  the  outputs.  It  also  supplies  the 
monitored  voltages  to  the  RSVP  processor. 

In  typical  integrated  circuit  processes  of  today,  supply  voltages  are  in  the  1 .5  to  5- volt 
range,  with  the  trend  towards  even  lower  voltages.  Lower  voltages  translate  to  lower 
power  consumption.  The  scavenged  power  sources  for  RSVP  may  produce  voltages 
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considerably  higher  than  5  volts.  For  RSVP,  AMI’s  1.2- micron  ABN  process  was  chosen. 
This  is  an  N-well,  14-mask  CMOS  process  with  2  metal  and  2  polysilicon  layers 
available.  It  is  available  at  low  cost  through  the  MOSIS  prototyping  service,  which  makes 
it  suitable  for  a  development  and  demonstration  project.  This  ABN  process  is  nominally  a 
5-V  process,  but  it  allows,  with  the  use  of  Poly2  transistors,  supply  voltages  in  the  range 
of  2.5  to  1 1  volts.  To  accommodate  these  higher  voltages,  larger  transistors  are  required 
with  a  minimum  gate  length  of  3.5  microns. 

The  power  module  ASIC  contains  the  elements  shown  earlier  in  Figure  11.  These 
elements  can  be  seen  in  Figure  17,  which  is  the  physical  layout  of  the  IC,  and  they  are 
described  in  greater  detail  in  the  following  subsections.  The  ASIC  is  approximately  2.2 
mm  square  and  has  44  bonding  pads  around  its  periphery. 

4.1 .9.9  DC-DC  Converter 

The  DC-DC  converter  is  used  to  transfer  energy  developed  by  the  scavenged  sources  and 
accumulated  on  the  input  capacitors  to  the  main  energy  storage  capacitor.  The  use  of  the 
DC-DC  converter  and  low-dropout  linear  regulator  allows  this  energy  transfer  to  take 
place  with  good  efficiency  over  a  wide  range  of  source  voltages.  For  a  linear  regulator 
alone,  the  maximum  efficiency  is  given  by  the  ratio  of  the  output  voltage  to  the  input 
voltage.  For  a  the  case  where  the  input  voltage  is  not  much  larger  than  the  output  voltage, 
this  efficiency  is  good,  however  if  the  input  voltage  is  several  times  the  output  voltage, 
the  efficiency  is  poor.  For  the  combination  of  the  DC-DC  converter  circuit  and  the  linear 
regulator,  the  efficiency  is  the  product  of  the  two  efficiencies.  If  the  DC-DC  converter 
output  is  adjusted  to  give  just  above  the  minimum  required  by  the  linear  regulator,  then 
the  efficiency  of  both  can  be  good  and  the  overall  efficiency  can  be  good  or  at  least  fair. 
Table  10  compares  the  relative  net  efficiency  for  both  approaches.  The  assumptions  are: 
DC-DC  converter  efficiency  is  80%,  the  output  voltage  is  3.3  V  and  the  linear  regulator 
requires  a  minimum  of  3.6  V  input.  This  table  shows  that  over  much  of  the  range  of 
expected  input  voltages,  that  the  combination  of  converter  and  linear  regulator  has  better 
efficiency  than  the  linear  regulator  alone. 
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Figure  17  Power  Module  ASIC  Layout. 


Table  10  Comparison  of  regulator  efficiencies. 


Input  Voltage 

Efficiency  -  linear 
regulator  only  (%) 

Efficiency  -  DC- 
DC  converter  and 
linear  regulator  (%) 

3.6  V 

92 

73 

5 

72 

73 

6.6 

50 

73 

10 

33 

73 

The  DC -DC  converter  circuit  used  is  shown  in  simplified  form  in  Figure  18.  This  type  of 
converter  is  called  a  Buck,  or  step-down  converter.  The  Buck  converter  produces  a  lower 
average  output  voltage  than  its  input  voltage.  This  mode  of  operation  is  known  as  the 
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forward  mode,  with  a  LC  filter  section  directly  after  the  power  switch.  Operation  of  the 
Buck  converter  consists  of  closing  the  switch  so  that  charge  flows  through  the  inductor 
and  into  the  capacitor  and  load.  The  current  passing  through  the  inductor  increases 
linearly  resulting  in  increasing  energy  storage  in  the  inductor.  When  the  switch  is  opened, 
the  energy  stored  in  the  inductor  cannot  change  instantaneously,  so  that  current  must  still 
continue  to  flow.  This  causes  the  voltage  at  the  input  of  the  inductor  to  fall  below  ground 
potential.  The  diode,  therefore,  becomes  forward  biased  which  provides  a  current  path. 
The  output  filter  capacitor  maintains  the  output  voltage,  at  least  temporarily.  As  the 
current  supplied  through  the  inductor  decreases  due  to  the  reversed  polarity,  the  load 
current  must  be  partially  supplied  by  taking  charge  from  the  output  capacitor  and  its 
voltage  decreases.  If  it  is  properly  sized,  this  voltage  drop  is  small  and  it  is  recharged  the 
next  time  the  switch  closes.  Regulation  is  accomplished  by  controlling  the  duty  cycle. 


4.1.9.9.1  DC-DC  Converter  Switch 

The  DC-DC  converter  switch  is  implemented  using  a  CMOS  transmission  gate 
constructed  using  the  second  polysilicon  layer  (poIy2)  MOSFETs.  The  use  of  the  poly2 
MOSFETS  allows  the  power  management  ASIC  to  withstand  up  to  1 1  Vdc  from  the 
scavenging  power  sources.  The  devices  making  up  the  transmission  gates  were  sized  to 
allow  at  least  10  mA  currents  to  be  passed  with  less  than  a  0.25V  drop.  Any  voltage  drop 
is  a  loss  in  efficiency  in  transforming  energy  from  the  sources.  For  the  expected  current 
levels  (less  than  1  mA)  from  the  scavenged  sources,  the  energy  loss  in  the  DC-DC 
converter  switch  should  be  negligible. 

These  transmission  gates  must  be  controlled  using  logic  signals  with  the  same  voltage  as 
the  dc  input,  but  they  must  be  derived  from  the  low  voltage  logic  signals  used  in  the  rest 
of  the  ASIC  (3.6  to  5  V).  This  required  logic  level  translators,  and  these  were 
implemented  as  inverters  constructed  using  poly2  transistors  and  having  a  weak  PMOS 
device. 
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4. 1.9. 9. 2  Diode  and  Inductor 

The  non- ideal  diodes  actually  used  in  the  DC-DC  converter  exhibit  parasitic  resistance, 
leakage  current,  and  (non- zero)  forward  voltage  drop.  The  diode  also  needs  to  have  a  fast 
time  response  to  allow  rapid  change  from  forward  to  reverse  bias.  The  Schottky  diode 
family  characteristics  include  a  low  forward  voltage  drop  and  low  leakage  current.  These 
are  often  selected  for  DC-to-DC  conversion  applications  and,  therefore,  one  with  suitable 
characteristics  (10BQ015)  was  chosen  for  use  here. 

The  inductor  chosen  for  use  in  the  DC-DC  converter  is  a  1  mH  coil  (Toko  part  number 
181LY-102).  It  has  a  maximum  dc  resistance  of  3.4  ohms  and  a  maximum  dc  current  of 
90  mA. 

4.1.9.10  Main  Energy  Storage  Capacitor 

The  main  energy  storage  element  is  the  primary  repository  of  stored  energy  for  the  RSVP 
power  module.  In  general,  a  larger  value  would  be  preferred,  as  long  as  the  leakage  did 
not  represent  an  excessive  loss  of  power.  To  determine  the  lower  limit  on  the  capacitor 
value,  the  current  needs  of  the  system  were  considered.  During  a  typical  sensor  cluster 
operation,  there  is  a  current  drain  of  10  mA  for  2  milliseconds.  Since  ?  Q=  I  ?  t,  the 
charge  change  is  found  to  be  20  microcoulombs.  (We  assume  that  the  scavenged  current 
is  much,  much  less  than  this  current  and  may  be  ignored  for  this  calculation.  We  also 
assume  that  the  high  currents  required  by  RF  communications  are  supplied  by  the 
battery.)  If  the  linear  regulator  has  an  output  of  3.3  V  and  a  dropout  voltage  of  0.1  V,  then 
its  input  must  be  at  least  3.4  V.  That  voltage  is  the  output  of  the  power  source  switch.  If 
that  switch  has  a  voltage  drop  of  0.1  V  at  maximum  current  (10  mA),  then  the  voltage  on 
the  storage  capacitor  may  drop  by  no  more  than  0.1  V  to  maintain  regulation.  For  20 
microcoulombs,  this  leads  to  a  minimum  capacitor  size  of  200  microfarads.  We  chose  a 
very  conservative  value  of  20,000  |xF  (two  of  the  10,000  p.F  capacitors  like  those  using 
on  the  source  inputs). 

4.1.9.11  Power  Source  Switch 

Under  some  circumstances,  the  energy  contained  in  the  main  energy  storage  capacitor 
may  not  be  sufficient  to  allow  operation  of  the  sensor  cluster.  For  startup,  this  element 
will  be  completely  discharged.  The  power  module  will  start  with  the  power  source  switch 
set  to  select  the  primary  battery.  This  will  allow  the  power  module  to  start  its  own 
operation  and  to  almost  immediately  supply  power  to  the  other  modules.  Once  the  power 
module  senses  sufficient  voltage  (energy)  on  the  main  energy  storage  capacitor,  it  will 
use  the  power  source  switch  to  connect  the  output  regulators  to  the  main  energy  storage 
capacitor.  Should  the  voltage  of  the  main  energy  storage  capacitor  become  too  low,  the 
power  module  will  switch  back  to  the  primary  battery  until  the  voltage  of  the  main 
energy  storage  capacitor  exceeds  its  lower  limit.  The  processor  will  also  be  able  to 
control  the  power  source  switch.  If  the  sensor  cluster  requires  high  current  mode,  the 
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processor  can  force  the  power  module  to  switch  over  to  the  primary  battery  as  long  as 
needed. 

The  power  source  switch  is  implemented  using  two  CMOS  transmission  gates  to  form  a 
single-pole,  double-throw  (SPDT)  structure.  It  is  not  symmetric  -  the  transmission  gate 
for  the  battery  is  sized  to  allow  currents  of  up  to  100  mA  with  a  voltage  drop  of  no  more 
than  0.2  V,  while  the  other  transmission  gate  is  sized  to  allow  currents  up  to  20  mA  with 
a  voltage  drop  of  no  more  than  0.2  V. 

4.1.9.12  Voltage  reference 

A  band-gap  voltage  reference  is  included  in  the  power  module  ASIC.  Like  most  band-gap 
circuits,  its  nominal  output  is  approximately  1 .2  V.  This  voltage  is  amplified  and  buffered 
using  an  opamp  in  a  non- inverting  gain  configuration  to  produce  an  output  of  2.2  V.  To 
conserve  power,  the  reference  is  only  powered  up  periodically  (3  cycles  out  of  every  32). 
Since  the  linear  regulator  requires  a  continuously  on  voltage  reference,  the  output  of  the 
voltage  reference  is  sampled  using  a  simple  sample-and-hold  circuit  (transmission  gate 
and  hold  capacitor).  This  circuit  holds  the  voltage  reference  for  the  linear  regulator  until 
the  voltage  reference  circuit  is  powered  up  again  and  re-sampled.  The  schematic  for  the 
complete  voltage  reference  is  shown  in  Figure  19. 

Power  on/off 


Figure  19  Voltage  Reference  For  Power  Management  ASIC 


4.1.9.13  Voltage  level  monitors 

The  voltages  of  interest  (power  sources  and  main  energy  storage  capacitor)  are  examined 
using  voltage  level  monitors.  Each  voltage  monitor  consists  of  a  comparator,  a  voltage 
divider  and  a  connection  to  the  voltage  reference.  The  voltage  to  be  monitored  is 
connected  to  the  top  of  the  divider,  and  the  center  of  the  divider  is  connected  one  input  of 
the  comparator.  The  other  comparator  input  is  connected  to  the  voltage  reference.  This 
arrangement  gives  a  fixed  voltage  threshold.  Each  voltage  to  be  monitored  is  compared  to 
the  appropriate  threshold,  and  the  states  of  the  comparator  outputs  are  used  by  the  state 
machine  control  logic  to  control  the  operation  of  the  power  module.  For  example,  the 
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main  energy  storage  capacitor  voltage  is  monitored  for  a  fully-charged  level  and  a  “too- 
low”  level.  If  the  element  is  fully  charged,  then  the  charging  process  will  cease.  If  the 
element  is  between  the  two  levels,  it  will  be  charged  as  power  is  available.  If  the  element 
is  “too-  low”  then  the  module  will  switch  over  to  the  primary  battery  and  power  should  be 
conserved.  In  the  case  of  the  scavenged  power  inputs,  the  voltage  level  monitor  will 
determine  if  they  are  high  enough  to  merit  transferring  power  to  the  main  energy  storage 
element. 

The  voltage  limit  monitor  comparators  will  only  be  powered  up  as  needed  to  save  power. 
For  normal  operation,  the  voltages  are  checked  every  16  clock  cycles  (about  every  0.5 
ms).  Based  on  the  expected  charging  currents  and  load  currents,  this  should  be  frequent 
enough  so  the  power  management  module  should  always  function  properly.  For  the 
scavenged  power  sources,  the  voltage  is  checked  less  frequently  (every  64  clock  cycles) 
if  no  power  is  seen  for  several  monitoring  cycles.  A  comparison  takes  only  one  half  clock 
cycle  (16  microseconds),  so  even  the  normal  duty  cycle  for  the  comparators  is  very  low 
(3%).  This  reduces  the  average  power  taken  by  the  comparators  by  a  factor  of  32. 

The  limit  voltages  are  set  using  external,  high-value  resistors.  This  was  done  for  a 
number  of  reasons.  First,  this  allows  the  use  of  resistors  with  higher  values  (and  lower 
power  dissipation)  than  would  be  possible  with  on-chip  resistors.  (Precision  resistors 
above  about  50  kohm  are  excessively  large  when  fabricated  on-chip.)  Second,  the  use  of 
external  resistors  allowed  adjustment  during  prototype  development  and  fine-tuning  of 
production  units,  if  desired.  Third,  using  external  resistor  dividers  resolved  potential 
voltage  limit  problems.  Some  of  the  voltages  that  need  to  be  monitored  (sources)  may  be 
greater  than  the  operating  voltage  of  the  ASIC  (4-5  V,  only  the  DC-DC  switches  allow 
higher  voltages).  With  the  external  voltage  divider,  the  voltage  presented  to  the  ASIC  is 
always  less  than  the  operating  voltage. 


4.1.10  Control  logic  for  the  power  module 

A  state  machine  controls  the  operation  of  the  power  module.  In  normal  operation,  this 
control  logic  starts  the  power  module  by  drawing  power  from  the  primary  battery,  and 
then  checks  for  the  availability  of  scavenged  power  by  scanning  the  voltage  monitors.  If 
power  is  available,  it  then  turns  on  the  appropriate  dc-to-dc  converter  for  a  fixed  number 
of  cycles,  if  not,  it  waits  for  a  while  and  checks  again.  The  logic  also  checks  that  voltage 
of  the  main  energy  storage  capacitor.  If  this  voltage  is  high  enough,  it  switches  the  input 
of  the  linear  regulator  to  this  capacitor  (and  away  from  the  primary  battery.)  If  the  voltage 
of  the  main  energy  storage  capacitor  reaches  a  second,  higher  level,  then  it  is  deemed 
fully  charged  and  the  DC-DC  converters  are  turned  off  until  the  voltage  drops  below  that 
level.  This  process  continues  until  there  is  no  power  available,  or  the  unit  is  turned  off. 
The  control  logic  would  also  enable  the  secondary  output  regulators  depending  upon  the 
state  of  the  request  from  the  processor  module 

Figure  20  shows  a  simplified  timing  diagram  illustrating  this  operation.  Trace  A  shows  a 
source  voltage  that  gradually  increases.  This  represents  a  successful  scavenging 
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operation.  Trace  B  shows  comparator  signals  -  these  are  the  enables  of  the  voltage 
monitors.  During  the  time  when  these  signals  are  in  the  high  logic  state,  the  voltage 
monitors  are  turned  on  and  five  levels  (sources  1 ,  2  and  3,  and  main  energy  storage 
capacitor  lower  and  upper  levels)  are  checked.  This  on/off  cycling  is  done  to  save  power. 
Trace  C  shows  the  output  of  the  source  1  voltage  monitor.  It  goes  to  a  high  logic  level 
when  the  threshold  is  passed.  This  starts  the  clock  for  the  DC-DC  converter  (Trace  F), 
and  the  voltage  Of  the  main  energy  storage  capacitor  starts  to  rise  (Trace  D).  When  this 
voltage  reaches  the  minimum  limit  (Trace  E),  the  input  of  the  linear  regulator  is  switched 
so  that  it  draws  power  from  the  main  energy  storage  capacitor  (unless  the  processor 
indicates  high  power  mode  and  forces  it  to  draw  power  from  the  battery.)  Eventually,  the 
voltage  of  the  main  energy  storage  capacitor  may  increase  to  the  point  where  the 
maximum  threshold  is  passed  (Trace  G,  inverted  logic  used  here)  and  the  DC-DC 
converter  is  turned  off,  until  the  voltage  drops  back  below  the  maximum  threshold. 

Depending  upon  the  load  power  requirements  and  the  source  capabilities,  a  number  of 
operating  modes  are  possible.  Figure  20  illustrates  a  case  where  the  source  can  supply 
more  power  than  the  load  requires.  In  this  case,  the  DC-DC  converter  will  be  cycled  on 
and  off  and  the  main  energy  storage  capacitor  voltage  will  stay  between  the  minimum 
and  the  maximum  thresholds.  For  a  less  powerful  source,  the  DC-DC  converter  may  run 
continuously  and  the  maximum  threshold  may  never  be  reached,  but  the  level  will  stay 
above  the  minimum  threshold.  Alternatively,  the  load  may  draw  the  main  energy  storage 
capacitor  voltage  back  below  the  minimum  threshold,  and  the  logic  will  switch  back  to 
battery  power.  In  this  case,  the  module  may  cycle  between  battery  and  scavenged  power. 
Other  sequences  are  possible  if  the  load  and  sources  are  not  constant. 
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Figure  20  Power  module  ASIC  timing  diagram  with  control  signals. 
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4, 1 . 1 1  Linear  Regulator 

A  low-dropout  linear  regulator  is  the  source  of  the  main  output  (3.3V  nominal).  The 
regulator  is  capable  of  operating  over  a  wide  range  of  output  currents  (<100  pA  to 
>  100mA),  and  has  a  dropout  voltage  less  than  100  mV.  A  simplified  schematic  for  the 
regulator  is  shown  in  Figure  21.  It  consists  of  a  CMOS  opamp  and  a  PMOS  pass 
transistor.  Use  of  a  very  large  PMOS  pass  transistor  (width  =  20400  microns  and  length  = 
1.2  microns)  allows  the  output  to  approach  the  input  voltage  even  for  high  output 
currents.  The  gain-setting  resistors  are  chosen  to  set  the  output  to  3.3  V  with  a  2.2-V 
reference.  High-value,  external  resistors  were  used  to  allow  the  output  to  be  adjusted  (due 
to  uncertainty  in  the  reference  voltage)  and  reduce  the  power  needed  by  the  regulator 
circuit.  (Resistors  with  values  above  approximately  50  kohm  are  unreasonably  large 
when  implemented  as  part  of  the  ASIC.) 


Figure  22  illustrates  some  of  the  regulator’s  capabilities.  The  nominal  output  is  very 
nearly  3.3  V,  and  regulation  is  maintained  for  a  331 -ohm  load  (10  mA)  down  to  an  input 
of  3.322  V.  This  translates  to  a  dropout  voltage  of  about  25  mV  for  a  10  mA  load. 
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Figure  22  Linear  regulator  input/output  characteristics. 


4.1.11.1  Step-up  regulator 

Some  applications  of  the  power  module  require  a  secondary  output  voltage.  This 
secondary  voltage  is  supplied  by  an  external  step-up  regulator.  This  regulator  is  normally 
turned  off,  and  is  turned  on  by  a  control  signal  from  the  processor  module.  The  prototype 
power  module  includes  both  5-V  and  9-V  step-up  regulators.  Both  use  a  Linear 
Technology  LT1615  integrated  circuit.  The  on/off  function  is  achieved  using  a  PMOS 
device  (IRLML6302)  to  switch  the  power  to  the  converter  on  or  off. 

4.1.11.2  Power  Module  startup  and  shutdown 

The  power  module  uses  a  manually- controlled,  multi-pole  switch  to  connect  it  to  the 
various  power  sources  (primary  battery,  PV  module  and  alternate  power  sources.)  For 
storage,  this  switch  should  be  open  and  the  power  module  is  disabled  and  draws  no  power 
from  any  source.  On  startup,  the  switch  should  be  closed  and  the  power  module  ASIC 
will  start  operation.  To  cease  operation,  the  switch  should  be  opened  and  operation  will 
stop  after  power  is  exhausted  from  the  energy  storage  elements  (capacitors.) 
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4.1.11.3  Power  Module  and  Sensor  Cluster  Processor  Interface 

Table  1 1  shows  a  list  of  the  power  module  signals  connecting  to  the  sensor  cluster 
processor. 


Table  11  Power  Module  Interface  Signals. 


Signal 

Type 

Description 

Secondary  output 
voltage  enable 

Digital  input,  active 
high 

When  true  (high),  the  secondary  output 
voltage  converter  is  turned  on.  When  low 
(false),  this  converter  is  off. 

High  current  mode 
enable 

Digital  input,  active 
high 

When  true  (high),  the  power  module 
operates  in  the  high  output  current  mode 
and  draws  power  from  the  primary  battery. 
When  false  (low),  the  power  module 
internal  logic  determines  the  power  source 
(battery  or  capacitor  bank). 

Primary  battery 
voltage 

Analog  voltage 

For  monitoring  by  the  ADC 

Linear  regulator 
input  capacitor  bank 
voltage 

Analog  voltage 

For  monitoring  by  the  ADC 

Charging  circuit 
enable 

Digital  input,  active 
low 

When  true  (low),  the  power  module 
charging  circuits  are  enabled.  When  false 
(high),  they  are  disabled.  This  signal  is 
optional  and  may  not  necessarily  be 
supplied  by  the  processor. 

SMH 

Digital  output 

Buffered  copy  of  32kHz  oscillator  output 

Power  Ground 

Analog  power 

Return  path  for  supply  current 

3.3  V 

Main  regulated  supply  voltage 

Secondary  voltage 

Analog  power 

Secondary  output  voltage  (value  TBD) 

NSWCCD-TR-2003/02 


4.1.11.4  Results 

The  power  management  module  was  developed  in  several  stages.  In  the  first  stage,  the 
various  components  of  the  PMM  ASIC  were  fabricated  using  separate  elements  on  two 
ASICs.  These  were  tested  individually  for  function  and  performance,  and  then  were 
combined  into  a  power  management  module  as  shown  in  Figure  23.  The  logic  needed  for 
the  power  management  module  was  implemented  using  an  Altera  programmable  logic 
device  (PLD).  This  allows  the  state  machine  to  be  revised  as  needed  during  the 
development  stage.  Some  of  the  elements,  such  as  the  band  gap  reference,  were  made  in 
several  versions,  and  the  best  version  was  determined  during  testing. 


Figure  23  First  generation  power  management  module 
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A  second  generation  power  management  module  was  developed  with  an  ASIC  that 
included  all  of  the  elements  described  earlier,  except  for  the  control  logic.  This  logic  was 
left  external  and  in  a  PLD.  This  allowed  for  making  changes  to  the  logic,  but  is  not  a 
long-term  solution  as  the  power  requirement  of  the  PLD  is  a  sizeable  fraction  of  a  watt. 
This  second  generation  power  management  module  is  shown  in  Figure  24.  The  overall 
size  is  greatly  reduced  and  two  40-pin  DIP  ASICs  are  reduce  to  one  44- pin  PLCC.  Some 
components,  such  as  the  battery  pack  and  the  10,000  microfarad  capacitors  are  mounted 
on  the  rear  of  the  printed  circuit  board. 


Figure  24  Second  generation  power  management  module 


Finally  the  logic  was  incorporated  into  the  ASIC,  and  a  third  generation  power 
management  module  was  constructed.  This  is  shown  in  Figure  25.  As  before,  the  battery 
pack  and  the  rather  large  filter  capacitors  are  mounted  on  the  back  of  the  board.  This  is 
shown  in  Figure  26.  Figure  27  shows  a  close-up  of  the  ASIC. 
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Figure  25  Third  generation  power  management  module  front  view 


Figure  26  Third  generation  power  management  module  rear  view 
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Figure  27  Close-up  of  the  power  management  module  ASIC 

To  simulate  the  rest  of  the  sensor  cluster  and  to  facilitate  testing  of  the  power 
management  module,  a  load  test  board  was  developed  and  fabricated.  It  provides  the 
logic  signals  that  would  ordinarily  come  from  the  processor  module  and  draws  power  at 
the  levels  expected.  It  also  allows  monitoring  a  number  of  voltages  and  currents 
important  to  the  operation  of  the  power  management  module.  (Source  voltage  and 
current,  load  power  and  current,  etc.)  It  also  displays  some  of  die  key  logic  states  of  the 
power  management  module.  This  board  and  the  battery  box  associated  with  it  are  shown 
in  Figure  28.  Figure  29  shows  the  load  test  board  connected  to  the  power  management 
module.  The  circular  cable  is  the  normal  connection  to  the  rest  of  the  sensor  module, 
while  the  ribbon  cable  and  associated  connectors  are  used  by  the  load  test  board  only. 
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Figure  28  Load  test  board  and  battery  box 
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4, 1.1 2  Structural  Sensors 

Each  RSYP  Structural  Cluster  consisted  of  a  radio  board,  a  power  management  board  and 
sensor  connection  serial  ports.  The  radio  board  and  power  management  board  were 
described  and  discussed  in  Sections  4.1.8  and  4.1.9.  This  section  will  focus  on  the 
structural  sensor  types  and  the  reasoning  for  their  selection  including  the  possible 
implementation  philosophy  for  hill  RSVP  shipboard  installation. 

Each  RSVP  Structural  Cluster  contained  3  accelerometers  and  2  strain  gages.  The  3 
accelerometers  were  IC  Sensors  Model  3145-002  and  3140-100,  similar  to  those 
illustrated  in  Figure  1  and  had  ranges  of  2  G’s  and  100  G's.  The  strain  gages  were  Sarcos 
Research  Corporation  Uni- Axial  Strain  Transducers  (UAST)  illustrated  in  Figure  2. 
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The  Structural  Cluster  consisted  of  packaging  for  the  radio  and  power  management 
boards,  three  IC  Sensors  accelerometers  and  two  Sarcos  Research  Corporation  Uni- Axial 
Strain  Transducers  (UAST).  Installation  onboard  the  USS  MONTEREY  (CG-61)  is 
shown  in  Figure  3. 


Figure  32  RSVP  Structural  Cluster  (including  sensors)  installed  onboard  USS 

MONTEREY  (CG-61) 


Onboard  USS  MONTEREY  (CG-61)  the  Structural  Clusters  and  their  associated  sensors 
were  installed  on  continuous  longitudinal  shell  (T-beam)  stringers.  Ideally  this 
installation  would  have  been  most  effective  if  it  were  installed  on  the  ship’s  center 
vertical  keel  (CVK).  This  location  would  have  produced  the  most  useful  acceleration  and 
strain/stress  information  for  determination  of  the  ship’s  hull  condition  from  both  a  long 
term  trending  perspective  (corrosion  and  deterioration)  as  well  as  from  a  more 
instantaneous  battle  damage  assessment.  Additionally,  information  from  the  CVK  could 
be  correlated  to  ship’s  bending  moments  and  other  design  specifications  therefore 
establishing  a  baseline  comparison  capability.  But  due  to  the  inaccessibility  to  the  CVK 
the  next  closes  longitudinal  was  selected  and  it  was  more  than  sufficient  to  demonstrate 
the  technology  to  measure  /communicate/process  the  structural  data  and  exemplify  the 
extreme  usefulness  of  this  data  (as  described  in  the  demonstration  and  full  shipboard 
installation  paragraphs  below). 

For  the  USS  MONTEREY  (CG-61)  at-sea  demonstration  of  the  Structural  Clusters 
ability  to  measure,  communicate  and  process  data  into  knowledge,  the  accelerometers 
were  utilized  to  measure  acceleration  due  to  seaway  forces  as  well  as  simulated  “shock” 
excursions.  The  seaway  forces  that  were  produced  naturally  by  the  motion  of  the  ship  and 
were  measured  by  the  2  G  range  accelerometers.  The  “shock”  excursions  were  simulated 
by  utilizing  an  Instrumented  Modal  Hammer  to  impact-the  structure  (near  the  location  of 
the  accelerometer)  and  measure  the  response  with  the  100  G  range  accelerometer. 
Similarly,  the  strain  transducers  were  utilized  to  measure  strain/stress  of  the  structural 
member  due  to  seaway  forces  as  well  as  simulated  damage  conditions  by  using  a  constant 
strain  apparatus  to  drive  the  strain  transducer  to  its  highest  measuring  range.  This 
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Figure  33  Constant  Strain  Apparatus 


For  the  USS  MONTEREY  (CG-61)  in-port  VIP  day  demonstration  of  the  Structural 
Cluster  the  2  G  range  accelerometers  were  attached  to  a  structure  that  simulated  medium 
to  severe  seaway  motion/forces.  This  seaway  motion/force  simulation  device  is  illustrate< 
in  Figure  5. 


Figure  34  Seaway  Motion/Force  Simulation  Device 


The  preceding  explanation  and  description  of  the  Structural  Cluster  and  associated 
sensors  more  than  sufficiently  demonstrated  the  availability  of  technology  to  measure, 
communicate,  and  process  structural  data.  The  subsequent  amplification  further 
exemplifies  the  acute  usefulness  of  this  data  in  realistic  shipboard  scenarios. 
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As  a  minimum,  in  a  full  shipboard  RSVP  installation,  tri-axial  hull  accelerometers  and 
strain  transducers  would  be  used  for  the  following  fundamental  reasons. 

First  is  to  quantify  peak  amplitude  and  duration  time  of  G  forces  from  a  Shock  excursion 
both  at  the  location  of  the  first  (shock  wave)  contact  and  along  the  propagation  to 
equipment  and  machinery  locations  throughout  the  ship.  This  information  is  essential 
because  as  the  shock  wave  travels  through  (deforming)  decks  and  bulkheads  significant 
attenuation  of  the  peak  amplitude  will  occur.  Being  able  to  confirm  G  forces  and  stress 
levels  encountered  by  critical  (or  even  non- critical)  equipment,  machinery,  and  weapons 
systems  will  permit  the  ship  to  determine  if  any  systems  have  exceeded  their  G  force  or 
stress  level  specifications  and  therefore  may  not  be  “certified”  for  further  use  impacting 
the  readiness  of  the  ship  (and  possibly  the  Battle  Group)  to  continue  its  current  operation. 
There  are  many  other  similar  scenarios  of  this  type  that  illustrate  the  need  for  the  ship  to 
have  reliable  structural  information  to  make  informed  damage  assessment  and  damage 
control  decisions. 

Second  is  to  have  total  situational  awareness  of  G  forces  and  stress  levels  during  critical 
damage  control  situations  such  as  counter-  flooding,  fire  suppression,  damage 
containment  including  deck,  bulkhead  and  hull  stability,  and  additionally  the  reactions 
associated  with  these  initial  actions.  Again  there  are  many  other  similar  scenarios  of  this 
type  that  illustrate  the  need  for  the  ship  to  have  reliable  structural  information  to  make 
informed  damage  assessment  and  damage  control  decisions. 

Third  is  to  quantify  peak  amplitude  and  duration  time  of  G  forces  from  seaway  forces  and 
to  correlate  them  to  hull  strains/stresses  and  eventually  to  sea  state  equations  utilized  for 
foundation  and  structural  designs.  This  type  of  pragmatic  data  and  knowledge  would  not 
only  result  in  shipboard  structural  situational  awareness,  but  would  validate  many  design 
and  engineering  specification  documents  used  for  ship  design  and  construction. 
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4.1.13  Power  Harvesting 

4.1.13.1  Vibration-to-Electric 

RSVP  leveraged  the  work  performed  in  the  Phase  1  SBIR  OSD99-08,  performed  by  MJR 
Scientific  Corporation,  Salt  Lake  City,  UT.  MJR  was  tasked  to  develop  two  transducers 
for  RSVP  to  demonstrate  energy  harvesting  from  a  vibration  source.  The  ultimate  goal  of 
this  work  has  been  the  demonstration  of  the  feasibility  for  the  development  of  energy 
harvesting  from  all  types  of  machines  and  structures  to  facilitate  wireless  operation  of 
sensors  in  use  in  Condition  Based  Maintenance  (CBM)  systems. 


-  Electrical  Substrate  with  a 
Matrix  of  Coils  and  Circuits 


(a)  Energy  Harvesting  Source  (EH$) 
Substrate  with  Multitude 
of  Resonating  Structures 


Direction  of 
Motion  m 


Magtiet 


/Tofe* 

reporting  S&vc&jtc) 

j—  Planar  Coil 
/  Mechnical 
f~  and  Electrics! 
/  Substrates 

- 3 

200|im  to  5  mm 


j - 2  mm  to  10  mm - -| 

Section  A-A 

(b)  Cross  Section  View  of  a  Single  Energy  Harvesting  CelJ 


Figure  35  Energy  Harvesting  Source 


MJR  proposed  the  development  of  a  small  device  capable  of  providing  power  for  each 
sensor  and  associated  communication  circuits  for  wireless  transmission  of  the  sensor  data 
to  a  central  processing  station  onboard  a  ship.  The  aim  of  the  work  was  the  development 
of  a  small  Energy  Harvesting  Source  (EHS),  which  may  be  installed  with  or  next  to  each 
sensor  to  provide  electrical  power  needed  by  the  sensor  and  its  RF  communication 
circuits. 
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An  Energy  Harvesting  Source  (EHS,  shown  in  Figure  35),  consists  of  a  matrix  of  simple 
energy  harvesting  cells  (Figure  35  (a)).  A  basic  component  of  each  cell  is  a  small 
permanent  magnet  supported  with  a  Miniature  Resonating  Flexure  (MIZE).  MRF  (Figure 
35(b))  is  located  such  that  the  magnet  is  suspended  at  the  center  of  an  electrical  conductor 
in  a  shape  of  coil  (planar  or  three  dimensional).  When  attached  to  the  host  structure, 

MIZE  will  be  excited  by  the  vibration  of  the  frost  structure  causing  it  to  resonate.  The 
relatively  large  amplitudes  of  the  motion  created  by  MRF,  at  the  frequency  of  the 
operation  of  the  machine,  is  used  to  oscillate  the  magnet  at  the  center  of  the  coil.  The 
motion  of  magnet  induces  electromotive  force  (EMF)  in  the  coil  and  the  flow  of  electrical 
current  in  the  coil. 

A  single  EHS  consists  of  a  matrix  of  such  similar  cells  and  electrically  connected 
together  to  increase  the  quantity  of  the  harvested  energy.  This  approach  is  ideal  for  the 
development  of  energy  harvesting  technology  for  all  types  of  machines  which  run  at  one 
or  range  of  frequencies.  The  harvested  energy  may  be  stored  on  a  capacitor  or  used  to 
charge  a  battery  cell  for  use  by  the  sensor  and  the  RF  communication  circuit  for 
transmission  of  the  sensor  data. 

Two  EHS  devices  were  constructed  of  three  main  simple  components.  These  include:  1)  a 
substrate  with  tolls  and  basic  electrical  circuits;  2)  flexure  combined  with  magnetic 
materials;  and  3)  a  package  for  protection  of  the  EHS. 
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Figure  36  A  Simple  Connection  Of  Coils  In  Series  And  A  Diode  Bridge  For  Voltage 

Conversion 


The  series  connection  of  a  number  of  cells  allows  for  the  summation  of  their  potentials 
above  the  battery's  potential  (e.g.  about  1.25  volts  for  NiCad  cell)  required  to  charge  the 
battery.  Optionally,  the  energy  may  be  stored  on  a  capacitor. 

Both  devices  built  for  RSVP  were  designed  for  operation  at  a  vibration  level  of  1  g  at 
1000  rad/sec  .  The  two  transducers  were  also  used  to  show  the  summation  of  induced 
electrical  voltage  by  each  device  as  a  means  for  increasing  the  harvested  energy  by  a 
number  of  transducers.  The  vibration  transducers  were  designed,  constructed  and  tested 
before  delivery  to  the  RSVP  for  demonstration.  The  work  performed  included  a  large 
amount  of  electromagnetic  simulation  and  optimization  of  the  transducer  design.  In 
addition,  an  extensive  amount  of  testing  was  completed  to  validate  the  performance  of  the 
transducers  each  separately  and  together  on  a  hand-held  vibration  table. 

The  first  transducer  was  tuned  to  an  excitation  frequency  of  1000  rad/sec  and  when  tested 
at  lg  it  induced  about  lvolt.  The  second  transducer  was  tuned  to  a  slightly  lower 
frequency  to  show  addition  of  potentials  (by  connecting  the  transducers  in  series)  while 
both  devices  were  excited  together.  The  performance  of  both  devices  was  validated  by 

'k  iT  1  ** 


Figure  37  Transducer  Construction  With  A  Moving  Coil  As  A  Seismic  Mass 
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Figure  38  Transducer  Construction  With  A  Moving  Magnet  As  A  Seismic  Mass 


Since  the  conclusion  of  RSVP,  MJR  has  been  pursuing  the  development  of  energy 
harvesting  transducer  with  its  own  resources.  The  highlights  of  this  work  include: 

1.  A  draft  copy  of  patent  application  for  the  transducer  has  been  completed. 

2.  A  new  transducer  design  is  underway  to  increase  the  induced  voltage  at 
lower  machine  vibration  levels  (0.05  g  at  30  Hz)  to  5  to  7  volt.  The  new 
transducer  design  will  be  tested  by  the  end  of  November. 

3.  A  method  has  been  found  to  eliminate  the  use  of  voltage  amplification 
circuits  needed  to  charge  a  battery  cell. 
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4.1.13.2  Thermo-to-Electric 

RSVP  tasked  Hi-Z  Technology,  in  San  Diego,  CA.  to  develop  a  thermo-electric  power 
harvesting  device.  A  thermoelectric  generator  was  designed,  febricated  and  installed  to 
harvest  energy  freely  available  on  board  ship.  The  generator  uses  the  5°C  differences 
between  the  temperature  of  the  space  inside  of  the  ship  and  the  ship’s  hull. 

The  Energy  Harvesting  generator  is  used  to  charge  a  capacitor  to  at  least  4.5  Volts.  The 
capacitor  is  used  to  power  a  sensor  package,  supplied  by  others,  and  periodically  transmit 
the  data  obtained  wirelessly  to  a  central  command  point. 

The  design  consisted  of  a  large  number  of  thermoelectric  couples  that  were  required  to 
produce  the  3.5  to  4  Volts  required.  The  40  mW  thermoelectric  module  chosen  measures 
0.292"  x  0.292"  x  0.9"  and  operates  between250  C  and  25  C  in  the  RTG  configuration.  A 
picture  of  the  40  mW  module  is  shown  in  Figure  39. 


Figure  39  40  mW  Thermoelectric  Module 

A  large  array  of  modules  were  developed  into  an  energy  harvesting  generator.  The  energy 
harvesting  generator  was  installed  aboard  CG-61  in  MER  #2,  against  the  interior  of  the 
ship’s  hull  -  Figure  40.  The  hull,  which  is  cooled  on  the  outside  by  the  surrounding  ocean 
water,  acted  as  the  heat  sink.  The  ambient  air,  within  the  engine  room  space,  is  the  heat 
source.  The  energy  harvesting  generator  was  connected  to  the  PMM  during  the  RSVP  At- 
Sea  demonstration. 
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Figure  40  RSVP  Thermoelectric  Energy  Harvesting  Generator  Installed  on  CG61 

USS  MONTEREY 

The  complete  details  on  the  design  and  development  of  the  thermo-electric  energy 
harvesting  generator  are  contained  in  the  “Energy  Harvesting  Thermoelectric  Generator 
Final  Report”  [ref  12]. 
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4.2  Machinery  Health  Monitoring  System 


4.2.1  Overview 

This  section  describes  the  functions  and  capabilities  of  the  Machinery  Health  Monitoring 
System  (HMS)  developed  and  demonstrated  during  the  RSVP  ATD.  The  HMS  employs 
hardware  and  software  in  a  multi- layer,  distributed,  hierarchical  architecture  that 
monitored  portions  of  one  Ship  Service  Gas  Turbine  Generator  (SSGTG).  The  hardware 
and  software  elements  include  sensors,  data  acquisition,  signal  conditioning,  data 
analysis,  archival/retrieval,  and  control,  and  two-way  RF  communication.  The  Intelligent 
Component  Health  Monitor  (ICHM)  provides  component/subsystem  level  monitoring 
while  the  System  Health  Monitor  (SHM)  combines  ICHM  information  into  a  higher- level 
system  view.  An  overview  of  the  HMS  is  shown  in  Figure  41 . 
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Figure  41  Machinery  Health  Monitoring  System 
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4.2. 1.1  System  Health  Monitor  (SHM) 

The  System  Health  Monitor  (SHM)  integrates  data  from  multiple  ICHMs  and  other 
sensors  to  monitor  the  health  of  subsystems  and  provide  a  system  level  perspective.  The 
SHM  performs  complex  signal  processing,  data  fusion,  and  approximate  reasoning  that 
will  eventually  lead  to  predicting  the  remaining  useful  life  of  the  monitored  equipment. 
Communication  with  the  ICHM  and  AP  is  accomplished  via  two  independent  wireless 
RF  links.  The  SHM  serves  as  a  repositoiy  of  machinery  data/information  and  services 
data/information  requests  from  the  Watchstation,  Requests  for  lower  level  data  are  also 
handled  by  the  SHM  through  messages  requests  directed  to  the  ICHMs.  SHM  diagnostics 
consist  mainly  of  internal  processor  operation  check  and  communication  connectivity 
with  the  AP  and  ICHM. 

4.2. 1.2  Intelligent  Component  Health  Monitor  (ICHM) 

A  set  of  four  Intelligent  Component  Health  Monitors  (ICHMs)  monitor  portions  of  the 
SSGTG’s  four  main  subsystems;  the  turbine,  accessory  gearbox,  reduction  gearbox  and 
generator.  System  configuration  includes  one  ICHM  for  the  turbine  and  accessory 
gearbox,  one  for  the  reduction  gearbox  and  two  ICHMs  for  the  generator;  one  electrical 
and  one  mechanical.  The  ICHMs  include  multiple  sensors  and  processing  capability 
designed  to  monitor  mechanical  components  such  as  bearings,  gears,  motors,  and  other 
mechanical  components  and  detect  phenomena  such  as  acceleration,  temperature,  current, 
voltage  and  other  observable  parameters.  Processing  on  each  ICHM  integrates  the  sensor 
data  and  determines  health  and  status  of  the  component  being  monitored.  Self-diagnostics 
includes  sensor  fault  detection,  temperature,  system  processor  operation,  and 
communication  link  quality.  The  ICHM  reports  to  the  SHM  on  an  exception  basis  (alerts 
and  alarms),  services  and  responds  to  requests  from  the  SHM,  and  provides  a  component 
health- status  vector  at  set  intervals. 

The  sensed  parameters  associated  with  the  four  ICHMs  are  as  follows: 

Generator  (Electrical)-  ICHM  #1 
Current  Output  -  Phase  A 
Current  Output  -  Phase  B 
Current  Output  -  Phase  C 
Voltage  Output  -  Phase  A 
Voltage  Output  -  Phase  B 
Voltage  Output  -  Phase  C 
Exciter  Voltage 
Exciter  Current 
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Generator  (Mechanical)-  ICHM  #2 

Bearing  Vibration  -  Drive  End 
Bearing  Temperature*  -  Drive  End 
Bearing  Vibration  -  Drive  End 
Bearing  Temperature*  -  Drive  End 
Bearing  Vibration  -  Pma  End 
Bearing  Temperature*  -  Pma  End 
Bearing  Vibration  -  Pma  End 
Bearing  Temperature*  -  Pma  End 

*from  vibration  sensor  (internal  temperature  sensor) 

Reduction  Gearbox  -  ICHM  #3 

Bearing  Vibration  1  -  High  Speed  Shaft  Drive-End 
Bearing  Temperature  1  -  High  Speed  Shaft  Drive-End 
Bearing  Vibration  2  -  High  Speed  Shaft  Non-Drive-End 
Bearing  Temperature  2  -  High  Speed  Shaft  Non- Drive-End 
Bearing  Vibration  1  -  Low  Speed  Shaft  Drive-End 
Bearing  Temperature  1  -  Low  Speed  Shaft  Drive- End 
Bearing  Vibration  2  -  Low  Speed  Shaft  Non-Drive- End 
Bearing  Temperature  2  -  Low  Speed  Shaft  Non-Dnve-End 

Turbine/Accessory  Gearbox  -  ICHM  #4 
Engine  Module  Temperature 
Compressor/Engine  Surface  Temperature* 

Compressor/Engine  Vibration 
Bearing  Vibration  -  Vertical 
Bearing  Vibration  -  Horizontal  X 
Bearing  Vibration  -  Horizontal  Y 

*ffom  vibration  sensor  (internal  temperature  sensor) 

4.2.2  Hardware  and  Software  Requirements 

The  general  system  hardware  and  software  functional  requirements  for  the  SHM  and 

ICHM  are: 

•  Data  acquisition,  processing,  and  communications  control 

•  RF  communications 

•  Data  fusion  and  archiving 

•  Open  architecture/interfaces 

•  Scalability 

•  Application  of  machinery  diagnostics 
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The  drawing  in  Figure  42  shows  the  key  functional  components  of  the  SHM  and  ICHM. 
The  ICHM  includes  sensors,  signal-conditioning  electronics,  analog-to-digital 
conversion,  a  processor  to  control  data  acquisition  and  to  process  data,  and  a  radio  to 
provide  wireless  communication  to  the  SHM.  ICHM  software  controls  data  acquisition, 
processes  data,  performs  data  fusion  on  data  from  the  ICHM  sensors,  determines  the 
health  of  the  monitored  component,  and  communicates  data  and  health  messages  to  the 
SHM.  The  SHM  must  communicate  wirelessly  with  ICHMs  and  Access  Points,  provide 
data  archiving  and  database  management,  perform  data  fusion  on  information  from  the 
ICHMs,  and  control  the  operation  of  the  ICHMs  it  is  responsible  for. 


To  Access 
Point 


Figure  42  Functional  Components  of  SHM  and  ICHM 
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4.2.2. 1  ICHM  Functionality  and  Capability 

The  ICHMs  monitor  and  assess  the  health  of  a  machinery  component.  In  very 
broad  terms,  the  ICHM  must  sense  and  measure  physical  parameters,  make  some 
decision  about  the  condition  of  the  component  based  on  the  measurement,  and 
communicate  the  results  of  that  measurement  and  decision  to  the  SHM.  Other 
requirements  for  this  device  include  autonomous  wireless  operation,  self-test,  and 
calibration.  The  ICHM  is  field  programmable  to  permit  upgrades  to  data  analysis  and 
other  functions.  The  ICHM  is  (mostly)  digital,  and  includes  sufficient  processing  power 
to  support  data  acquisition,  analysis,  communication,  and  ICHM  control. 

Specific  functions  of  the  ICHM  include: 

•  Data  acquisition,  including: 

o  Parameter  sensing  (e.g.,  temperature,  pressure,  vibration) 
o  Signal  conditioning  (e.g.,  sensor  power,  filtering,  amplification) 
o  Data  conversion  (multiplexing,  A/D  conversion) 
o  Acquisition  control  (synchronization,  timing,  sequencing) 
o  Data  analysis  and  alerts 

o  Communication  (receive  control  and  synchronization  messages  from 
SHM,  transmit  data  and  alerts  to  SHM) 

•  System  support,  including: 

o  System  control  (control  communication,  data  acquisition,  data  analysis, 
system  clock) 

o  Software  support  (ROM,  RAM,  program  loader) 
o  Power  management 

o  Self- test  (ICHM  self-diagnostics,  watchdog  timer  control) 
o  Physical  interfaces  (sensor  attachment,  operator  control,  cabling,  module 
interconnect,  etc.) 

A  generalized  block  diagram  of  the  ICHM  is  shown  in  Figure  43. 
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Figure  43 ICHM  Block  Diagram 


The  ICHM  module  contains  a  host  processor  and  a  data  acquisition  board  that  controls 
the  acquisition,  processing,  and  transfer  of  data  via  a  standard  set  of  processing  and  I/O 
functions.  The  ICHM  is  field-configurable  and  adaptable  offering  upgrade  flexibility  to  a 
variety  of  applications  over  time.  To  support  a  variety  of  machinery  health  monitoring 
scenarios,  the  device  software  structure  provides  an  easy-to-use  interface  to  acquisition 
and  processing  functions.  An  assortment  of  tools  is  provided  to  allow  rapid  development 
and  integration  of  new  processing  tools  as  they  become  available.  The  system  software 
employs  a  multitasking  environment  that  permits  the  installation  of  individual  user 
processes  on  top  of  a  system  structure  providing  utilities  required  for  algorithm 
development.  This  structure  eliminates  the  need  for  the  diagnostic  algorithm  developer  to 
modify  underlying  support  software  to  support  communications,  self- tests,  and  resource 
management. 

The  ICHM  provides  data  acquisition,  processing,  and  wireless  network  hardware  and 
software  to  accomplish  the  conditioning,  digitization,  acquisition,  calibration,  and  local 
processing  sensor  data.  Initially,  temperature,  pressure,  vibration,  and  tachometer 
measurement  types  will  be  supported.  The  configurable  acquisition  module  design 
supports  a  wide  variety  of  measurements  including;  temperature,  pressure,  vibration, 
tachometer,  current,  voltage,  strain,  position,  etc.  The  ICHM  supports  the  varied  dynamic 
range,  signal  conditioning,  and  data  bandwidth  requirements  of  a  variety  of  sensing 
elements.  This  includes  support  for  different  sample  sizes  up  to  12  bit  and  associated 
transfer  rates. 
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4.2.2.2  SHM  Functionality  and  Capability 

The  SHM  monitors  and  assesses  the  health  of  an  entire  system  using  the  resources 
of  its  associated  ICHM  nodes.  Certain  types  of  analysis  may  require  that  measurements 
from  several  ICHMs  be  acquired  simultaneously;  therefore,  a  means  of  temporal 
synchronization  by  the  SHM  across  ICHMs  may  eventually  be  required.  This  type  of 
ICHM  synchronization  was  not  implemented  as  part  of  the  RSVP  demonstration  system. 
The  SHM,  like  the  ICHM  is  field-programmable  to  permit  upgrades  to  the  system- level 
machinery  diagnostic  and  prognostic  functions.  Like  the  ICHM,  the  SHM  is  (mostly) 
digital,  with  sufficient  processing  power  to  support  data  acquisition,  analysis, 
communication,  ICHM  control,  and  higher-  level  system- wide  functions,  such  as  context- 
based  reasoning,  data  archival  and  management,  and  dynamic  system  modeling.  SHM 
support  functions  include  power,  self- test,  and  physical  interfaces.  Figure  44  illustrates 
the  functional  organization  of  the  SHM. 


The  general  requirements  for  SHM  functionality  include: 

•  Feature- level  and  decision- level  data  fusion 

•  Support  for  algorithms  or  programs  to  confirm  or  further  process  available  data, 
such  as  automated  context-based  reasoning,  neural  networks,  fuzzy  logic,  and 
dynamic  system  models 

•  Data  archival  and  management  for  large  amounts  of  data 

•  RF  communications  to  the  ICHM  via  Open  Air  Standard  wireless  Ethernet  radio 

•  RF  communications  to  the  Access  Point  via  802.1 1  compliant  Ethernet  radio 
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•  Network-configurable  software  throughout  the  system  allowing  rapid  software 
upgrades  and  fixes  as  well  as  algorithm  updates 

•  Scaleable,  extensible,  portable,  and  reusable  architecture 

•  Low  risk  COTS  hardware 

•  Support  for  NDDS  communications  with  AP  and  Human  Computer  Interface  at 
the  Watchstation 

Note:  System  level  (SSGTG)  data  fusion  was  not  incorporated  into  the  SHM  as  part  of 
the  RSVP  demonstration  because  of  limitations/restrictions  associated  with  installing 
additional  sensors  or  accessing  existing  sensor  signals  on  the  SSGTG  from  the  machinery 
control  system  aboard  the  demonstration  ship. 

4.2.2 .3  HMS  Architecture 

The  hardware  and  software  architecture  is  designed  to  be  expanded  or  reduced  as 
appropriate  to  meet  the  specific  requirements  set  forth  by  the  system- level  application(s). 
The  operating  system  and  developmental  software  supports  migration  toward  new 
processors  and  peripherals.  Local  data  archival  of  acquired  data  supports  system-  level 
trending  as  well  as  context-based  reasoning  of  acquired  and  processed  data  results. 
Designed  into  the  HMS  but  not  implemented  for  the  demonstration,  the  system 
automatically  ages  acquired  and  processed  results  in  order  to  manage  the  local  database. 
Aging  consists  of  discarding  older  data  as  it  becomes  obsolete,  based  on  the  type  of  data 
and  standard  aging  algorithms.  All  data  collected  during  the  demonstration  period  was 
archived  to  aid  in  analysis  of  the  HMS  performance. 
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4.2.3  Hardware 

4.2.3.1  Overview 

The  Machinery  Health  Monitoring  System  consists  of  three  primary  components; 
sensors,  Intelligent  Component  Health  Monitors  (ICHM),  and  a  System  Health  Monitor 
(SHM).  Installation  and  Ship’s  interface  hardware  include  power  supplies,  an 
instrumentation  interface  box  for  sensors  attached  to  the  SSGTG  and  associated  brackets 
for  mounting  the  hardware.  In  order  to  meet  strict  guidelines  for  installing  temporary 
equipment  on  the  SSGTG  skid,  the  HMS  hardware  was  designed  to  provide  a 
straightforward  means  of  installation  and  removal  without  altering  the  SSGTG  skid. 

Upon  removal  of  the  HMS  system  the  SSGTG  skid  was  returned  to  its  original  condition. 

As  such  the  instrumentation  interface  box,  power  supply  cabinet,  and  power  supplies 
were  designed  specifically  for  the  shipboard  prototype  installation.  A  fmal/permanent 
installation  would  be  more  integrated  with  the  SSGTG  skid  and  somewhat  simplified. 
Specifically,  power  would  come  from  on  the  skid  thereby  eliminating  the  need  of  the  four 
power  supplies  supporting  the  HMS  as  well  as  the  rather  large  cabinets  containing  them. 
The  sensors  themselves  would  become  integrated  with  the  SSGTG  sensor  suite, 
eliminating  the  need  for  the  instrumentation  interface  box. 

General  locations  of  the  HMS  hardware  is  shown  in  Figure  45.  Primary  components  are 
shown  in  green,  while  installation  specific  components  are  shown  in  blue.  Detailed 
installation  and  removal  plans  develop  as  part  of  the  Interim  Logistics  Support  (ILS) 
Package  were  reviewed  and  approved  by  NSWCCD  codes  9332  and  9334  prior  to 
installation  at  LBES  and  on  the  ship. 
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hms  pwr  supply  &  shm  3rd  beck 


Figure  45  HMS  Hardware  Installation  Locations 


4.2.3.2  Sensors 

All  sensors  used  for  the  HMS  system  were  commercially  available.  Locations  of  sensors 
installed  on  the  SSGTG  are  shown  in  Figure  46.  Sensors  associated  with  each  ICHM  are 
described  in  Table  12,  Table  13,  Table  14,  and  Table  15. 
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4.2.3.3  ICHM 

The  ICHM  hardware  consists  of  PC104  form  factor  boards;  CPU,  power  supply, 
PCMCIA  Radio  and  Carrier,  A/D  Board,  5  Channel  Filter  Board  and  Connector  Board  - 
Figure  47.  All  boards  are  commercially  available  with  the  exception  of  the  filter  and 
connector  boards  -  Figure  48  and  Figure  49.  These  boards  were  designed  and  fabricated 
by  ARL  to  support  unique  demonstration  requirements.  The  PC  104  boards  are  stacked 
and  packaged  in  an  environmentally  sealed  extruded  aluminum  container  designed  to 
accommodate  PC  104  form  factor  boards.  The  ICHM  containers  were  modified  to 
accommodate  input  power  and  external  antenna  mount  for  radio.  In  anticipation  of  high 
AGB/Turbine  and  RGB  module  temperature  ICHM  #3  and  #4  were  fitted  with  thermo¬ 
electric  coolers.  Temperatures  experienced  in  both  modules  however  proved  to  be  within 
acceptable  limits  that  would  have  allowed  the  ICHMs  to  operate  without  the  thermo¬ 
electric  coolers.  An  Internal  ICHM  sensor  monitored  the  temperature  as  part  of  the  HMS 
own  health  monitoring  capability. 


Figure  47  ICHM  Hardware 
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4.2.3.3.1  Custom  ICHM  Boards 
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Figure  48  Filter  Board 
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Figure  49  Connector  Board 
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4.2.3.4  SHM 

The  SHM  utilized  a  commercially  available,  rugged,  smallPC  with  an  EBX  single  board 
233  MHz  Pentium  computer,  WinNT  OS  and  2  PC  104  expansion  slots  -  Figure  50.  The 
SHM  was  modified  to  accommodate  3  additional  PC/ 104  cards  including  internal  power 
supply  (DC  to  DC)  and  two  2.4  GHz  radios  (one  based  on  the  Open  Air  Standard  the 
other  IEEE  802.1 1)  via  PCMCIA  carriers.  The  demonstration  system  was  configured 
with  256  MB  of  RAM,  and  a  20  GB  laptop  hard  drive.  Configured  with  SVGA,  4  serial 
ports,  parallel  port,  and  10/100  Ethernet  connection,  the  SHM  computer  supported 
connection  of  keyboard,  mouse  and  monitor  for  system  development  but  were  not  used 
during  the  demonstrations.  The  SHM  was  designed  to  automatically  boot  up/reboot  and 
operate  without  operator  intervention,  including  cases  in  which  power  is  lost  or  the 
processor  hangs  up. 


Figure  50  SmallPC  -  SHM 


4.2.4  Software 

4.2.4.1  Overview 

The  ICHM  and  SHM  hardware  provide  the  physical  devices  and  means  to  acquire  data 
from  sensors  mounted  on  the  machinery,  transmit  data,  health  information,  and  alerts  and 
alarms  to  the  watchstation,  and  archive  information  related  to  the  health  of  the 
machinery.  The  software  running  on  the  ICHM  and  SHM  enable  these  functions.  The 
ICHM  software  controls  data  acquisition,  data  processing  and  feature  extraction,  data 
fusion  for  individual  ICHM  sensors,  performs  classification  and  generates  alert  and  alarm 
messages.  The  SHM  software  controls  communication  with  the  ICHMs,  collects  data, 
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alert  and  alarm  messages  from  the  ICHMs  and  provides  that  information  to  the 
watchstation,  and  archives  data,  processed  parameters,  and  alert  and  alarm  messages. 

4.2.4.2  Communication  Interface 

The  communication  interface  specifies  the  methods,  architecture  and  protocol  to 
communicate  data  between  the  RSVP  Health  Monitoring  System  (HMS)  and  the  Access 
Points  (APs).  The  interface  between  the  RSVP  access  point  and  health  monitoring 
subsystem  is  required  to  communicate  (HMS)  machinery  data  and  health  status 
information  to  both  the  access  point  and  the  RSVP  user  Watchstation.  Watchstation  data 
required  from  the  HMS  subsystem  is  routed  through  the  access  point.  The  access  point 
routes  Watchstation  requests  to  the  HMS  subsystem.  HMS  publications  are  sent  to  the 
WS  via  the  AP. 

4. 2.4.2. 1  Overview 

The  protocol  chosen  to  support  the  information  exchange  is  the  Network  Data  Delivery 
Service  (NDDS)  based  upon  a  publish/subscribe  paradigm.  Using  this  protocol, 
subscription  requests  are  sent  to  the  HMS  and  an  interface  between  the  HMS  data  and 
NDDS  is  responsible  for  obtaining  the  necessary  HMS  data,  bundling  it  into  NDDS 
messages  and  publishing  of  those  messages. 

Communication  within  the  HMS  subsystem  uses  TCP/IP  socket  connections.  The  HMS 
data  manager  thread  host  a  socket  connection  for  to  the  NDDS  interface  server  to 
communicate. 

Various  message  formats  are  used  to  communicate  over  the  TCP/IP  link  and  the  NDDS 
link.  HMS  to  AP/WS  message  formats,  as  well  as  published  data  organized  by  parametric 
or  series,  is  described  in  the  section  4.2.4.2.2.  Parameter  data,  organized  by  major 
monitored  component,  includes  parametric  messages  for  the  SSGTG  generator;  reduction 
gear,  auxiliary  gearbox  and  engine,  and  correspond  to  the  display  of  major  components  in 
the  Watchstation  GUI. 

Each  of  the  component  measured  parameters  is  requested  from  the  HMS  sub -system  via 
the  TCP/IP  stream  socket  connection  and  the  resulting  message(s)  are  used  to  formulate 
an  NDDS  response.  The  response  is  sent  via  the  NDDS  PSStatic  SendData  member 
function. 

Parametric  messages  are  in  the  form  of  variable  length  messages.  Each  message  contains 
one  or  more  parameters,  such  as  an  associated  timestamp,  location  and  component 
identifier.  Each  of  the  parameters  in  the  message  are  named  and  include  the  value  and 
data  type  of  the  data. 

In  addition  to  providing  HMS  NNDS  server  services  to  the  rest  of  the  network,  the 
interface  allows  requests  to  be  made  which  support  changing  HMS  parameters  from  the 
Watchstation  or  an  AP.  This  functionality  facilitates  user  inputs  to  change  programmable 
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system  parameters.  The  setting  of  parameters  is  supported  by  a  parametric  message 
structure,  which  originates  at  the  Watchstation  GUI  and  is  sent  to  the  appropriate  node. 


4. 2. 4. 2. 2  HMS  to  AP/WS  Message  Data  Formats 

Since  health  monitoring  data  will  vary  widely  between  monitored  machinery,  it  is 
desirable  to  establish  data  formats  that  are  flexible  with  regard  to  the  type  and  number  of 
parameters  that  may  be  required.  Two  options  were  considered  for  use  in  the  RSVP  HMS 
system 

One  solution  is  to  develop  distinct  message  formats  for  each  piece  of  equipment 
monitored.  In  this  approach,  the  data  types  of  the  parameter  sets  are  explicitly  defined. 
This  approach  is  efficient  in  terms  of  message  size  requirements  and  would  have  suited 
the  limited  scope  of  the  RSVP  demonstration.  However,  to  extend  this  approach  beyond 
the  demonstration  program,  modifications  to  the  parsing  software  would  have  to  be  made 
for  each  newly  developed  format. 

The  other  solution  considered  (and  selected  for  RSVP),  is  to  provide  a  message  format 
that  is  parsed  easily  without  an  a-priori  knowledge  of  the  message  format.  Using  this 
approach,  the  number,  type  and  name  of  the  message  parameters  are  embedded  in  the 
message.  The  parsing  of  these  messages  still  requires  software  that  is  responsible  for 
understanding  each  named  parameter  within  a  message;  however,  this  could  be 
accomplished  at  the  Watchstation  by  configuring  datamap  entries  for  the  user  interface. 

The  datamap  dispatches  named  parameters  based  upon  a  runtime  configuration.  By 
modifying  the  runtime  configuration,  data  can  be  mapped  to  user  interface  indicators 
without  modifying  the  underlying  software.  This  is  not  only  advantageous  for  system 
extensibility  but  facilitated  the  User  Interface  development  process.  New  indicators  could 
be  added  and  associated  with  data  elements  without  changing  the  underlying  interface 
code. 

To  accommodate  a  variable  length  and  type  message,  the  format  shown  in  Table  16  and 
Table  17  was  selected.  Time  series  and  frequency  spectra  message  formats  were  treated 
separately,  as  shown  in  Table  18,  to  allow  more  efficient  network  utilization  for  large 
data  records. 

Health  vectors  were  treated  as  a  special  case  of  parametric  data.  Each  parameter  in  the 
parameter  message  format,  as  shown  in  Table  16,  is  used  to  represent  a  corresponding 
health  vector  field.  Table  19  illustrates  the  parametric  message  format  used  to  represent  a 
health  vector. 
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Table  16  Parametric  Data  Format 


Data  Type 

Description 

ULONG 

Time/Date  in  ANSII  standard  format:  seconds  since  January  1, 1970 

ULONG 

Time  in  microseconds  for  higher  precision  time  stamps 

CHAR 

Byte  ordering  (big  vs.  little  endian) 

UINT 

Location  ID  identifies  the  compartment/location  of  the  machine 

ENUM 

Machinery  ID  Identifies  the  machine  being  monitored 

ULONG 

Length  in  Bytes  of  data  to  follow 

PARAM 

PARAM 

Parameter  2  {  see  Table  2  ) 

PARAM 

Parameter  n  (  see  Table  2  ) 

Table  17  Parameter  Structure 


PARAM 

Description 

Structure 

TYPE 

UINT 

UCHAR 

Type  -  Identifies  the  parameter  type  as  integer,  long,  short  string,  etc. 

UCHAR 

Bytes  corresponding  to  the  data  type  above.  Strings  are  NULL  terminated. 
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Table  18  Time  Frequency  Message  Formats 


Data  Type 

Description 

ULONG 

Time/Date  in  ANSII  standard  format:  seconds  since  January  1,  1970 

ULONG 

Time  in  microseconds  for  higher  precision  time  stamps 

UINT 

Location  ID  identifies  the  compartment/location  of  the  machine 

ENUM 

Machinery  ID  Identifies  the  machine  being  monitored 

ULONG 

Length  number  of  data  bytes  in  this  message 

UCHAR 

Data  Type  (float,  double,  integer,  long,  etc.) 

UINT 

Number  of  Channels 

FLOAT 

Sample  Rate  of  the  Data 

FLOAT[  ] 

FLOAT[  ] 

UINT 

Given  in  Type  Field 
Given  in  Type  Field 
Given  in  Type  Field 

Calibration  array  -  Multiplier  to  scale  the  data  (  0  -  none;  one  multiplier 
per  channel) 

Offset  array  -  DC  offset  for  data  (one  offset  per  channel) 

Domain  -  Time  (1)  or  Frequency  (2) 

Channel  1 ,  Sample  1 

Channel  2,  Sample  1 

Channel  3,  Sample  1 

Given  in  Type  Field 

Channel  N,  Sample  1 

Given  in  Type  Field 

Channel  1 ,  Sample  2 

Given  in  Type  Field 

Channel  2,  Sample  2 

Given  in  Type  Field 

Channel  3,  Sample  2 

: 

Given  in  Type  Field 

Channel  N,  Sample  2 

Given  in  Type  Field 

Channel  1 ,  Sample  N 

Given  in  Type  Field 

Channel  2,  Sample  N 

Given  in  Type  Field 

Channel  3,  Sample  N 

Given  in  Type  Field  Channel  N,  Sample  N 
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Table  19  Health  Vector  In  Parameter  Message  Format 

I  Data  Type  Description 


ULONG _ Time/Date  in  ANS11  standard  format  seconds  since  Jan  I,  1970 


ULONG 

Time  in  microseconds  for  higher  precision  time  stamps 

CHAR 

Byte  ordering  (big  vs.  little  endian) 

UINT 

Location  ID  identifies  the  compartment/location  of  the  machine 

■on 

Machinery  ID  Identifies  the  machine  being  monitored 

ULONG 

Length  in  Bytes  of  data  to  follow 

UINT 

Parameter  ID1  -  Fault  Type  ID 

UCHAR 

Type  -  Integer 

INT 

Fault  ID# 

UINT 

Parameter  ID2  -  Severity 

UCHAR 

Type  -  Integer 

INT 

Severity  level  (0-1) 

UINT 

Parameter  ID3  -  Confidence 

UCHAR 

Type  -  float 

FLOAT 

Confidence  level  (  0-1 ) 

UINT 

Parameter  ID4  -  Threshold 

UCHAR 

Type -float 

FLOAT 

Threshold  level  (0-1) 

UINT 

Parameter  IDS  -  Time  to  Threshold  (seconds) 

UCHAR 

Type  -  float 

FLOAT 

Time  to  Threshold  Value 

4.2.4.23  Interface  Design  Specification 

The  structure  of  the  AP  to  HMS  protocol  is: 

1 .  An  NDDS  request  is  made  to  a  HMS  NDDS  server  process  to  begin  a  publication 
or  set  a  parameter. 

2.  Upon  receipt  of  the  request,  the  HMS  NDDS  sever  process  requests  all  HMS  data 
messages  necessary  to  formulate  the  output  NDDS  message  via  a  TCP/IP  stream 
socket  connection  to  the  HMS  data  manager  thread. 

3.  Each  HMS  request  responds  with  a  status  indicating  that  the  request  is 
valid/invalid  and  a  maximum  wait  time  for  the  data. 

4.  The  HMS  NDDS  Server  Process  responds  to  the  AP/Watchstation  request  with  a 
status  indicating  the  validity  of  the  request. 

5.  In  the  event  that  an  error  is  found  by  the  HMS  NDDS  server  process,  an  error  is 
sent  to  the  requesting  NDDS  node  to  indicate  failure. 


127 


NSWCCD-TR-2003/02 


6.  In  the  event  that  no  error  is  indicated,  the  HMS  NDDS  server  waits  until  the 
stream  socket  connection  receives  requested  data.  The  timeout  is  dependent  on  the 
maximum  wait  time  specified  in  3.  In  the  case  of  a  parameter  setting  request,  the 
process  is  complete  at  this  point. 

7.  Each  time  an  HMS  message  corresponding  to  a  requested  data  type  is  read  by  the 
NDDS  interface  thread  at  the  HMS,  it  is  used  to  formulate  the  NDDS  response. 
When  more  than  one  HMS  message  is  required,  the  current  output  NDDS 
structure  is  updated  for  each  input  HMS  message  until  an  entire  set  of  inputs  is 
received.  When  the  entire  set  of  inputs  has  been  received,  an  internal  status  resets 
the  output  message  state  to  allow  a  new  set  of  updates.  For  parameter  settings,  a 
received  setting  of  the  actual  value  is  used  to  send  the  message. 

8.  The  resulting  message  is  published. 

Items  7  and  8  are  repeated  until  a  request  to  stop  is  sent  to  the  HMS  data  manager  thread 
or  a  time  out  occurs.  When  the  HMS  NDDS  server  receives  a  request  to  stop  publishing, 
requests  are  sent  to  the  HMS  data  manager  to  stop  sending  the  requested  data  set(s). 
Figure  51  illustrates  the  HMS  interface  data  flow. 
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Figure  51  Interface  Flow  Diagram 


The  TCP/IP  portion  of  the  protocol  will  operate  by  opening  a  connection  to  the 
HMS  sub-system  using  a  windows  stream  socket  application  layer  interface.  The  HMS 
data  management  services  will  be  configured  to  accept  a  stream  connection  at  an  address 
dedicated  to  the  NDDS/HMS  interface.  When  a  socket  connection  is  established  the 
HDDS  layer  will  forward  the  request  for  data  to  the  HMS  and  wait  for  a  response 
indicating  whether  the  operation  succeeded.  The  NDDS  layer  will  then  wait  for  incoming 
messages  from  the  HMS.  The  HMS  will  continue  to  send  updates  until  a  request  to  stop 
sending  the  data  is  received.  Each  time  a  structure  corresponding  to  the  requested  data  is 
received,  the  NDDS  layer  will  publish  it  back  to  the  Watchstation.  To  accommodate  a 
variable  length  and  type  message,  the  format  shown  in  Table  20  is  used.  The  general 
format  consists  of  a  master  header  followed  by  a  series  of  messages.  The  type  and 
number  of  messages  are  specified  in  the  header.  All  messages,  regardless  of  type  have  the 
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same  header  format,  specified  in  Table  21.  Table  22contains  enumerations  of  various 
parameters  within  the  master  header: 

Semaphore:  Error  checking  word  to  validate  the  message  header 

Message  type:  Type  of  message 

Time/Data:  UTC  time  stamp  of  message 

Microtime:  Time  in  microseconds  for  additional  time  precision. 

Location  ID:  Compartment  Location 
Machine  ID:  Machine 
Component  ID:  Machine  Component 

RequestID:  Unique  number  of  request  used  for  parsing  of  the  message  by 
requestor 

Length:  length  in  Bytes  of  data  following  master  header 
#Messages:  Number  of  messages  of  <message  type>  to  follow 


Table  20  Generic  HMS  Message  Structure 


Data  Type 

Description 

HEADER 

MASTER  HEADER  (TABLE  2-H 

MSG 

MESSAGE  1  fOF  TYPE  SPECIFIED  IN  HEADER  ) 

mu 

MESSAGE  2  (OF  TYPE  SPECIFIED  IN  HEADER) 

MSG 

MESSAGE  N  (OF  TYPE  SPECIFIED  IN  HEADER) 

Table  21  TCP/IP  HMS  Master  Header 


Data  Type 

ULONG 

Description 

Semaphore  word  0xAAAA5555 

IHRISRlcfli 

Message  type  (Interface  +  Message/Request/Response  Type)  (Enumerations  in  Table  2-2) 

ULONG 

TIME/DATE  IN  ANSII  S  TANDARD  FORMAT:  SECONDS  SINCE  JANUARY  1.  1970 

ULONG 

TIME  IN  MICROSECONDS  FOR  HIGHER  PRECISION  TIME  STAMPS 

ULONG 

LOCATION  ID  IDENTIFIES  THE  COMPARTMENT/LOCATION  OF  THE  MACHINE 
(ENUMERATIONS  IN  TABLE  2-2J 

ULONG 

MACHINERY  ID  IDENTIFIES  THE  MACHINE  BEING  MONITORED  (ENUMERATIONS  IN  TABLE  2- 
2) 

COMPONENT  ID  IDENTIFIES  THE  COMPONENT  BEING  MONITORED  (ENUMERATIONS  IN 

TABLE  2-2> 

ULONG 

ULONG 

REQUEST  ID  IDENTIFIES  THE  NDDS  DATA  REQUEST  MESSAGE  ID 

ULONG  LENGTH  IN  BYTES  OF  DATA  TO  FOLLOW  AFTER  THIS  HEADER 
ULONG  #  OF  THIS  MESSAGE  TYPE  TO  FOLLOW 
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Figure  52  Interface  Timing 


4. 2. 4. 2. 5  Software  Structure 

The  HMS  software  architecture  is  designed  to  emulate  the  functionality  of  an  AP  in  terms 
of  NDDS  connectivity.  The  interface  to  HMS  NDDS  publications  will  be  via  the  dynamic 
publish  subscribe  method  developed  for  the  AP  to  WS  interface  section  4.53.4 

An  NDDS  Server  resides  on  the  HMS  to  perform  the  function  of  translating  between 
NDDS  and  TCP/IP.  For  the  NDDS  request  type,  a  class  was  defined  that  is  a  sub-class  of 
the  cPSStatic  class.  The  server  is  responsible  for  translating  HMS  information  and 
bundling  it  into  the  respective  NDDS  requested  message  class.  The  server  also  provides 
the  facilities  for  setting  up  and  maintaining  a  stream  socket  connection  to  the  HMS  data 
manager  thread  via  TCP/IP.  .  The  server  provides  functions  for  opening,  reading  and 
writing  the  stream  socket  connection.  Error  handling  of  socket  data  is  also  included  in 
this  server. 
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To  support  the  remote  setting  of  parameters,  a  parameters  class  is  included  and  it  inherits 
the  functionality  of  the  HMS  socket  class  and  the  NDDS  derived  base  class.  NDDS  is 
used  to  perform  a  client/server  request  to  set  a  particular  named  parameter  value.  The 
actual  value  set  is  in  tum  sent  back  as  a  response  to  the  client  server  request. 


4.2.4.3  ICHM 

The  ICHM  runs  an  MS-Windows  operating  system.  The  ICHM  software  controls  data 
acquisition  and  processing,  fuses  data  from  multiple  ICHM  sensors,  classifies  component 
health,  and  generates  alert  and  alarm  messages  to  the  SHM.  The  operation  and 
functionality  of  the  ICHM  is  controlled  via  an  ASCII  text  script  file.  An  example  of  script 
file  is  shown  in  Figure  53.  The  main  ICHM  program  parses  the  script  file  and  executes 
the  commands. 

4.2.43.1  Data  Acquisition 

Data  acquisition  (AcquireData  command  in  script  file)  is  controlled  by  specifying  the 
range  of  channels  (start  channel,  stop  channel),  sample  frequency,  number  of  samples, 
and  the  name  of  the  file  in  which  to  save  the  resulting  data.  Data  are  stored  in  files  on  a 
solid-state  static  RAM  disk.  Raw  data  can  also  be  compressed  using  zip  utilities  for 
storage  on  the  ICHM  and  for  transmission  of  raw  data  files  to  the  SHM, 

4.2.43.2  Data  Processing 

Data  processing  on  the  ICHM  is  performed  using  executable  programs  called  by  the  main 
script  processing  program.  The  RunMatlab  command  in  the  script  file  specifies  the 
executable  program  used  to  process  the  data,  the  data  file  and  the  parameter  file  (with 
extension  ini).  The  RunMatlab  command  name  comes  from  the  fact  that  the  data 
processing  executable  programs  are  executable  versions  of  Matlab  m- files  generated 
using  the  Matlab  compilers  and  math  libraries.  All  processed  data  results,  processing 
parameters,  and  ICHM  configuration  information,  and  current  alert  and  alarm  messages 
are  all  stored  in  an  initialization  file  stored  on  the  ICHM  (ichmlparams.ini  in  the  example 
script).  The  initialization  file  provides  the  “memory”  for  the  ICHM  from  one  processing 
cycle  to  another. 

A  call  to  execute  the  ProcessICHMRawData.exe  executable  program  extracts  the  ICHM- 
specific  parameters  from  the  raw  data  file  and  updates  processed  data  parameters  in  the 
initialization  file.  The  ProcessICHMAlertData.exe  executable  program  determines  the 
health  of  the  components  monitored  by  the  ICHM  based  on  the  processed  data  or 
features,  thresholds,  and  other  settings  stored  in  the  specified  ICHM  initialization  file. 
Appropriate  alert  and  alarm  messages  are  generated  or  updated  and  stored  in  the 
initialization  file.  The  ProcessICHMParamFile.exe and  ProcessICHMAlertFile.exe 
executable  files  generate  parameter  and  alert  message  files  for  transmission  to  the  SHM 
based  on  the  information  contained  in  the  ICHM  initialization  file. 
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4.2.4.33  ICHM  Control 

ICHM  operation  is  controlled  by  the  script  file  as  described  earlier.  In  addition  to 
controlling  the  acquisition  of  data,  the  script  file  also  controls  communication  from  the 
ICHM  to  the  SHM.  Other  commands  define  the  ICHM  ID,  set  the  current  working 
directory,  put  the  ICHM  in  “sleep”  mode  for  a  specified  duration  (the  delay( )  command 
in  the  example  script  file).  The  ICHM  can  be  accessed  from  the  SHM  as  a  mapped  disk 
drive.  The  SHM  can  halt  execution  of  an  ICHM  at  which  time  the  ICHMs  script  file  can 
be  replaced.  When  execution  resumes  on  the  ICHM,  the  ICHM  will  begin  executing  the 
commands  in  the  new  script  file. 

4.2.43.4  ICHM  to  SHM  Communications 

The  original  concept  of  operations  for  the  machinery  health  monitoring  system  called  for 
the  ICHM  to  send  alert  and  alarm  messages  to  the  SHM  asynchronously  whenever  the 
status  of  the  health  of  the  component  monitored  by  the  ICHM  changed.  Similarly,  the 
ICHM  would  send  parametric  or  raw  data  to  the  SHM  upon  request.  This  operational 
mode  is  preferred  when  the  ICHM  is  operated  on  battery  power  to  preserve  battery  life.  A 
disadvantage  of  this  approach  is  that  the  SHM  also  needs  a  way  to  know  that  the  ICHM  is 
actually  functioning  and  has  nothing  to  report  instead  of  being  inoperable.  This  is 
typically  solved  by  having  the  ICHM  send  a  periodic  heartbeat  message  to  the  SHM. 
Since  the  ICHMs  in  the  RSVP  installation  were  not  operated  on  batteries  and  power  to 
the  ICHMs  was  not  an  issue,  it  was  decided  to  have  the  ICHMs  send  the  full  parameter 
and  alert/alarm  information  to  the  SHM  on  each  processing  c>cle.  This  is  accomplished 
by  the  SendSHMMessage  command  in  the  script  file. 

4.2.4.4  SHM 

The  SHM  is  responsible  for  controlling  operation  of  the  ICHMs,  receiving  raw  data, 
processed  data  and  alert/alarm  messages  from  the  ICHM,  archiving  processed  and  raw 
machinery  data,  and  serving  requested  parameters,  alert/alarm  messages  and  parameter 
trend  data  to  the  watchstation. 

4.2.4.4.1  Communications  Control 

Machinery  health  monitoring  system  information  and  data  from  the  SHM  to  the 
watchstation  are  routed  through  the  RSVP  access  points.  Conversely,  the  access  point 
will  route  Watchstation  requests  to  the  HMS  subsystem.  The  protocol  chosen  to  support 
the  information  exchange  is  the  Network  Data  Delivery  Service  (NDDS).  The 
functionality  of  this  protocol  is  based  upon  the  NDDS  publish/subscribe  paradigm.  Using 
this  protocol,  subscription  requests  will  be  sent  to  the  HMS  and  an  interface  between  the 
HMS  data  and  NDDS  will  be  responsible  for  obtaining  the  necessary  HMS  data,  bundling 
it  into  NDDS  messages  and  publishing  of  those  messages.  Communication  within  the 
HMS  subsystem  (between  the  SHM  and  ICHMs)  was  implemented  using  TCP/IP  socket 
connections.  An  HMS  data  manager  thread  running  on  the  SHM  hosts  a  socket 
connection  to  the  NDDS  interface  server.  Communication  between  the  SHM  and  the 
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ICHMs  is  handled  over  socket  connections.  Control  of  the  ICHMs  is  achieved  by 
remotely  logging  into  the  SHM  and  accessing  the  ICHMs  as  mapped  logical  devices. 

4. 2. 4. 4. 2  Scheduling 

The  ICHMs  communicate  asynchronously  with  the  SHM.  Because  the  ICHMs  operate  on 
ship’s  power  instead  of  batteries,  there  is  no  penalty  on  the  amount  of  communication 
between  the  ICHM  and  SHM  -  any  possible  penalty  for  bandwidth  use  is  further 
minimized  by  processing  the  data  on  the  ICHM  and  only  sending  a  relatively  small 
amount  of  data  to  the  SHM  in  each  message. 

4.2.4.43  Data  Fusion 

The  original  concept  of  operations  called  for  data  fusion  at  the  SHM  to  determine  the 
health  of  individual  components  within  the  HMS  system  and  to  reduce  false  alarms 
related  to  machinery  health  by  correlating  machinery-related  health  information  with  both 
existing  SSGTG  signals  and  environmental  and  structural  information.  Several  factors 
resulted  in  the  elimination  of  this  data  fusion  role  for  the  SHM.  First,  the  design  of  the 
ICHMs  permitted  each  ICHM  to  acquire  enough  sensor  data  to  sufficiently  determine  the 
health  of  major  subsystems  on  the  SSGTG.  Much  of  the  data  fusion  functionality  that 
was  originally  to  be  implemented  at  the  SHM  was  actually  implemented  on  the  ICHMs 
due  to  the  availability  of  the  data  at  that  level.  Second,  access  to  existing  signals  for  the 
SSGTG  was  not  possible  within  the  scope  of  the  project.  Although  fusion  of  the  existing 
SSGTG  signals,  health  data  and  features  from  mechanically  coupled  components  on  the 
SSGTG  could  be  used  to  improve  the  reliability  of  the  information  and  could  potentially 
reduce  false  alarms  or  alerts,  it  was  not  necessary  and  was  not  implemented.  At  the 
system  level,  environmental  and  structural  data  from  the  access  points  was  not  provided 
to  the  SHM  (the  access  points  only  published  data  “up”  to  the  watchstation  and  not 
“down”  to  the  SHM);  therefore,  the  SHM  was  not  able  to  fuse  machinery  health 
information  with  environmental  and  structural  information. 

4. 2. 4. 4. 4  Data  Archival 

Although  it  is  not  shown  in  the  example  ICHM  command  script,  the  ICHM  can  compress 
data  files  (using  standard  zip  utilities)  and  send  the  compressed  data  to  the  SHM.  The 
ICHMs  also  send  to  the  SHM  the  initialization  files  and  files  containing  parameter  data 
and  alert/alarm  messages.  All  of  this  information  is  archived  at  the  SHM.  Compressed 
data  files  (containing  the  data  from  all  channels  along  with  the  updated  initialization  file) 
are  stored  in  directories  corresponding  to  each  ICHM.  The  SHM  also  maintains  a 
Microsoft  Access  database  with  the  processed  data  parameter  or  features  for  each  ICHM. 
The  database  is  used  to  respond  to  specific  data  and  trend  requests  from  the  watchstation. 
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Test  script  file  for  ICHM  1 


’  DatalD’s  Currently  Defined 

’  1  -  Raw  Voltage  and  Current  (8  channels) 

'  2-  ICHM  Internal  Temp 

1  3-  Raw  ACCEL  Data 

1  4-  ACCEL  Temp 

'  5-  Sensor  Bias 

'  6-  External  Temp 

'  Start  by  reading  in  Calibration  data 

1  And  seting  up  gain 

DirectoryPrefix(C:\) 

’ICHM1D  (Location, Machine, Component) 

ICHM  ID(0, 1,2) 

ReadCalInfo(CalibrationFile  I  .txt) 

Delay(4000) 

’  Go  Get  8  Voltage  and  Current  channels 

’  AcquireData(LowChannel,HighChannel,SampleRate,NumSamples,DataID,FileName) 

AcquireData(0, 7,22000, 44000, 1  JLowSpeed2.dat) 

1  Get  ICHM  Internal  Temp 

AcquireData(  1 4, 1 4, 1 000,1 000, 2,IchmTmp.dat) 

RunMatlab(ProcessICHMRawData.exe  Iowspeed2.dat  ichmlparams.ini) 
RunMatlab(ProcessICHM  RawData.exe  ichmtmp.dat  ichmlparams.ini) 

RunMatlab(ProcessrNl AlertData.exe  ichml  params.ini) 

RunMatlab(Process!CHMParamFile  ichmlparams.ini  ichml  params.shm) 
RunMatlab(ProcessICHMAIertFIle  ichmlparams.ini  ichml alerts.shm) 
sendshmmessage(Info,  Now  we  process  parameter  file) 
sendshmmessage(Process,ichm  1  params.shm) 
delay(1000) 

sendshmmessage(Info.  Now  we  process  alert  file) 

SendSH  MMessage(Process,  ichm  1  alerts.shm) 
delay(IOOCO) 


Figure  53  Example  ICHM  Script  File 
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4.2.5  Operational  Characteristics 

4.2.5.1  Machinery  Virtual  Presence 

This  section  describes  the  operational  characteristics  of  the  machinery  health  monitoring 
system  in  support  of  machinery  virtual  presence.  Defining  machinery  virtual  presence  as 
follows; 

•  Sum  total  of  all  information  and  knowledge  needed  to  operate  and  manage  all 
aspects  of  a  piece  of  machinery  or  machinery  system  in  multiple  contexts. 

•  Accomplished  by  fusing  data  from  multiple  sources  to  determine  the  static  and 
dynamic  operational  state  and  condition. 

•  Information/knowledge  conveyed  in  a  coherent,  navigable  efficient  user  interface 
supporting  the  management  of  complex  systems  with  fewer  people. 

The  machinery  health  monitoring  system  provided  information  in  five  categories. 

1 .  Operation  monitoring 

2.  Performance  monitoring 

3.  Alerts  and  alarms 

4.  Component  health  diagnostics  and  prognostics 

5.  Maintenance  recommendations 

Note:  A  subset  of  the  information  described  below  was  implemented  for  the  actual 
demonstrations  based  on  sensor/signal  access  limitations  of  the  installed  system.  Even  so, 
the  final  installed  system  demonstrated  the  capability  to  provide  virtual  presence 
information  in  the  five  identified  categories. 

Operation  and  Performance  Information 

The  operation  information  includes  the  machine  settings,  and  readout  information  the 
operator  would  have  at  the  machine  or  in  the  engineering  operation  center.  Performance 
monitoring  information  provides  the  user  at  the  watch  station  with  an  assessment  of  how 
well  the  machine  is  operating  and  includes  information  such  as  efficiency,  and  pressure 
and  temperature  ratios.  Parameter  trending  supports  both  operational  and  performance 
information  categories.  Examples  of  Operation  and  Performance  Information  is  shown  in 
Figure  54and  Figure  55. 
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Figure  55  SSGTG  Electrical  Power  Generation  Performance  Information 


Alerts  and  Alarms 

There  are  two  basic  types  of  alert  and  alarm  messages/information:  operational  and 
component  health.  Operational  alerts  and  alarms  are  generated  when  a  sensor  reading  is 
out  of  the  normal  operating  range  (alarm)  or  when  the  sensor  reading  is  close  to  being  out 
of  range  and  is  continuing  to  change  in  a  manner  that  will  result  in  the  reading  being  out 
of  range  within  some  set  time  window  (alert).  Component  health  alert  and  alarm 
messages  warn  the  operator  that  the  condition  of  a  particular  component  has  degraded  to 
the  point  that  it  should  be  replaced  (alarm)  or  that  the  component  is  degrading  and  will 
need  replacement  within  the  some  set  time  window  (alert).  An  alert  is  considered  a 
precursor  to  an  alarm  and  provides  a  warning  that  an  alarm  condition  is  developing.  A 
third  type  of  alert  is  associated  with  the  monitoring  system  itself,  providing  an  indication 
of  an  adverse  condition  that  could  impact  the  performance  of  the  monitoring  system. 

Alert  and  alarm  information,  along  with  component  health  diagnostics  and  prognostics, 
comprise  the  ‘health-monitoring’  portion  of  the  HMS.  From  a  health  monitoring 
perspective,  operational  range  violations  may  serve  as  indicators  of  required  maintenance 
actions  or  developing  component  faults,  but  merely  indicate  that  an  adverse  condition 
already  exists.  On  the  other  hand,  a  successful  diagnostics/prognostic  capability  would 
provide  an  indication  of  a  developing  adverse  condition  and  the  time  it  will  take  to  reach 
an  unacceptable  condition.  Valid  diagnostics/prognostics  will  reduce  the  number  of 
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operational  range  violations  that  occur,  by  detecting  and  alerting  the  operator  in  a 
proactive  manner. 

Alert  and  alarm  messages  were  mapped  to  functional  areas  of  the  SSGTG.  At  the  highest 
level,  the  health  monitoring  system  alerts  and  alarms  are  associated  with  four  subsystems 
on  the  SSGTG: 

•  Generator  -  Electrical 

•  Generator  -  Mechanical 

•  Reduction  gear  box 

•  Accessory  gear  box 

Alert,  Alarm  and  System  Health  messages  are  shown  in  the  lower  portion  of  the  User 
Interface  Data  Screen  in  Figure  56. 


Figure  56  Examples  of  Alert,  Alarm  and  System  Health  Information 
Component  Health  Information 
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Component  faults  are  grouped  by  functional  components  within  the  gas  turbine  generator. 
Electrical  generator 

•  Stator  winding  deterioration  (including  tum-to-tum,  coil-to-coil,  and 
phase-to-phase) 

•  Rectifier  diode  failure 

•  Field  deterioration 

•  Operating  parameters  out  of  limits  (voltage,  current,  power  factor, 
frequency,  etc.) 

Mechanical  generator 

•  Generator  drive- end  bearing  fault 

•  Generator  other-end  bearing  fault 

Reduction  gearbox 

•  PTO  shaft  fault 

•  Front  bearing  fault 

•  Rear  bearing  fault 

•  RGB  gear  fault 

Accessory  gearbox 

•  AGB  drive  shaft  fault 

•  AGB  gear  fault 

•  AGB  bearing  fault 

An  example  of  Generator  Mechanical  Component  Health  Information  is  also  shown  in 
the  middle  of  the  right  screen  in  Figure  56  above. 

Maintenance  recommendations 

Maintenance  information/recommendations  associated  with  abnormal  -  alert/alarm 
conditions  were  reported  by  the  HMS  in  the  form  of  text  messages  displayed  at  the 
Watchstation.  The  capability  to  link  this  information  to  maintenance  and  repair 
procedures  was  included  as  a  function  of  the  Watchstation  User  Interface  but  not 
implemented  for  the  demonstrations  -  Figure  57 
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4.2.5.2  Information  Processing  and  Flow 

This  following  section  describes  the  information  processing  and  fusion  employed  in  the 
RSYP  machinery  health  monitoring  system.  The  HMS  organization  is  described  from 
two  points  of  view:  from  the  machinery  system,  and  from  the  health  monitoring  system. 
From  the  machinery  system  point  of  view,  the  system  can  be  described  as  a  collection  of 
subsystems  composed  of  components  that  can  be  further  described  as  a  collection  of 
elements.  From  the  health  monitoring  system  viewpoint,  the  system  is  composed  of  a 
watch  station,  access  points,  system  health  monitors,  integrated  component  health 
monitors,  and  sensors  -  Figure  58. 

The  object  of  the  machinery  health  monitoring  system  is  to  push  as  much  data  and 
information  processing  as  possible  down  to  the  integrated  component  health  monitor 
level.  This  has  the  advantage  of  reducing  the  bandwidth  required  to  send  the  health 
information  up  to  the  watch  station.  Bi-directional  event/query  driven  communications  is 
supported  between  the  lowest  and  highest  levels  of  the  system.  The  goal  is  to  limit 
communication  from  the  lowest  to  the  highest  leve  Is,  to  alert  messages  indicating  a 
problem  (event)  with  a  particular  machine  component.  An  alert  is  generated  by  the 
system  when  it  detects  that  a  fault  indicator  will  reach  a  set  alarm  level  within  a  specified 
time  threshold.  This  means  that  the  system  should  never  actually  reach  an  alarm  state 
because  the  machinery  health  monitoring  system  should  generate  an  alert  message  prior 
to  reaching  the  alarm  state.  On  the  other  hand,  an  operator  can  at  any  time  request 
data/information  (query)  from  any  level  within  the  system  all  the  way  down  to  individual 
sensor  readings. 

In  general,  the  processing  flow  in  the  machinery  health  monitoring  system  follows  the 
following  order:  calibration,  processing,  feature  extraction,  Kalman  filtering,  decision 
logic,  fusion.  The  Kalman  filter  is  used  to  provide  smoothed  feature  tracks  from  one  data 
snapshot  to  the  next  and  to  predict  the  future  machine  state.  Sensor  and  decision  level 
fusion  are  used  to  increase  or  decrease  confidence  in  the  fault  assessment. 
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The  machinery  health  monitoring  system  employs  a  hybrid  data  fusion  approach.  Data 
were  processed  and  fused  only  at  the  ICHM.  No  access  to  existing  signals  and  limited 
ability  to  add  additional  sensors  prevented  planned  processing  and  fusion  at  the  SHM.  At 
the  ICHM  level  -  equivalent  to  the  sensor  level  in  classic  military  data  fusion 
applications  -  sensor  data  are  first  calibrated,  then  processed  using  filtering,  FFTs, 
wavelets,  or  other  techniques  to  enhance  the  signal  to  noise  ratio.  After  initial  processing, 
thresholding  or  other  techniques  are  used  to  determine  whether  the  sensor  output  contains 
signals  of  interest.  Relevant  features  are  extracted  from  the  measured  data.  The  features 
are  processed  with  Kalman  filters  to  smooth  the  data  and  predict  the  future  value. 

Initial  planned  efforts  at  the  SHM  are  described  here  to  provide  the  reader  with  an 
understanding  of  how  the  HMS  system  would  be  implemented  if  signals  were  available. 
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Figure  58  Information  Processing  and  Flow  From  Sensor  to  WS 
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4.2.5.2.1  Electrical  Generator  Health  Monitoring 

Processing  of  the  generator  electrical  signals  at  ICHM  #1  (generator  electrical)  is  shown 
in  Figure  59.  The  sensor  signals  are  shown  in  blue  at  the  left  of  the  figure.  The  first 
processing  step  involves  the  computation  of  FFTs  of  all  of  the  signals.  The  signal  spectra 
are  searched  to  locate  peaks.  For  the  electrical  signals,  these  occur  at  the  main  output 
frequency  (nominally  60  Hz)  and  harmonics.  In  addition  to  identifying  peaks,  the  peak 
statistics  are  also  computed.  Peak  statistics  include  the  RMS  level,  frequency,  signal-  to- 
noise  ratio,  and  associated  variances.  The  spectral  peak  and  associated  statistical 
information  are  fed  into  Kalman  filters  that  provide  smoothed  track  information  for  the 
features  and  predict  future  feature  values. 

Operational  data  that  may  be  displayed  at  the  watch  station  are  shown  at  the  bottom  of 
the  figure.  These  include  the  individual  signal  spectra,  the  output  voltage,  output  current, 
load  power,  power  factor,  and  output  frequency.  The  generator  electrical  component 
features  are  passed  to  decision  logic  that  determines  whether  a  fault  condition  exists.  The 
use  of  the  Kalman  filter  permits  projection  of  the  measured  state  into  the  future  enabling 
the  system  to  assess  whether  a  fault  will  reach  an  alarm  state  within  the  prescribed  time 
window. 
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Figure  59  Generator  Electrical  Feature  Extraction  and  Operational  Data  Processing 
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After  processing  the  electrical  features  with  the  Kalman  filters,  the  feature  information  is 
passed  to  decision  logic  that  identifies  fault  conditions.  This  process  is  shown  in  the 
Figure  60.  The  output  of  the  Kalman  filters  includes  both  smoothed  tracks  of  the  current 
machine  state  as  well  as  a  prediction  of  the  future  machine  state  (i.e.  the  future  values  of 
file  features  associated  with  the  electrical  components).  The  future  machine  state  is 
predicted  at  some  time  t  into  the  future,  where  t  represents  the  required  warning  time 
required  before  the  system  enters  an  alarm  state.  The  decision  logic  checks  the  current 
condition  of  the  system  and  generates  an  alarm  message  if  a  fault  is  determined  to  exist. 

If  the  decision  logic  detects  a  fault  condition  using  the  predicted  system  state,  then  an 
alert  message  is  generated  indicating  that  an  alarm  will  occur  at  time  t  in  the  future  is  the 
system  continues  to  operate  in  its  current  state. 

All  of  the  decision  processing  shown  in  this  figure  takes  place  at  the  generator  ICHM 
(ICHM  #1).  Thresholds  and  tolerance  limits  are  downloaded  to  the  ICHM  from  the  SHM. 
The  fault  information  is  passed  to  the  SHM  as  a  health  vector.  The  health  vector  contains 
die  electrical  component  features,  feature  statistics,  the  fault  severities  and  indication  of 
whether  and  alert  or  alarm  was  generated. 


Figure  60  Generator  Electrical  Fault  Processing 
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4.2.5.2.2  Bearing  Health  Monitoring 

The  processing  of  bearing  vibration  signals  used  to  extract  vibration  related  features  is 
shown  in  Figure  61 .  The  raw  time-domain  signals  are  first  calibrated  (not  shown  in  the 
figure),  then  the  signal  statistics  are  calculated  and  FFTs  of  the  signals  are  computed.  The 
FFTs  are  used  to  update  power  spectrum  estimates  and  as  the  basis  for  subsequent 
processing.  The  physical  dimensions  of  the  bearings  are  used  to  compute  defect 
frequencies.  The  signal  spectrum  is  searched  for  narrowband  energy  at  the  defect 
frequencies  as  an  indicator  of  bearing  damage.  If  energy  is  present  at  related  defect 
frequencies,  additional  processing  is  performed  to  extract  potential  features. 


Defect  frequencies: 

•  Outer  raceway 

•  Inner  raceway 
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•  Cage 

Modulation  energy  at  defect 
frequencies 

Frequency  band  energy 
and  signal  statistics 


Enveloped  power 
spectrum  features 

Broadband  noise 
Signal  statistics 


Accessor)  Gearbox  ICHM  tIOHYl 


Figure  61  Bearing  Vibration  Feature  Extraction 


After  computing  the  vibration  related  features,  a  Kalman  filter  is  used  to  smooth  the 
feature  tracks  and  predict  the  future  feature  values  within  the  alert  time  threshold.  The 
processed  features  are  then  passed  to  the  fuzzy- logic  classifier  to  determine  bearing  fault 
confidences.  If  temperature  data  are  available  for  the  bearing,  the  temperature  data  are 
processed  to  update  the  signal  statistics,  then  filtered  with  the  Kalman  filter  to  produce 
smoothed  signal  tracks  and  predict  the  future  signal  values.  The  predicted  temperature 
data  are  used  to  increase  or  decrease  the  confidence  in  the  bearing  fault  predictions.  This 
process  is  shown  in  Figure  62. 
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Figure  62  Bearing  Fault  Processing 


Features  and  symptoms  for  bearing  outer  and  inner  race  faults  and  symptoms  for  bearing 
rolling  element  and  cage  faults  are  shown  in  Table  23  and  respectively.  Outer  race  faults 
are  indicated  by  signal  energy  related  to  rolling  element  pass  outer  raceway  (RPOR) 
defect  frequencies  while  inner  race  faults  are  indicated  by  signal  energy  related  to  rolling 
element  pass  inner  raceway  (RPIR)  defect  frequencies.  Rolling  element  faults  are 
indicated  by  features  related  to  rolling  element  spin  (RSPIN)  defect  frequencies  while 
cage  faults  are  indicated  by  signal  features  related  to  the  cage  defect  frequency. 
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Table  23  Outer  and  Inner  Race  Bearing  Faults 


Fault  /  Enhanced  Features 

Fault  Symptoms 

Bearing  Outer  Race  Fault 

Enveloped  Power  Spectrum  RPOR 
defect  frequency  energy 

Presence 

EnvPS  RPOR  harmonics  energy 

Presence 

Baseband  lx  RPOR  defect  frequency 

Presence 

Frequency  band  kurtosis 

Above  variance,  growing  -early:  Above  and  decreasing  -  late 

Frequency  band  noise  floor 

Increasing  in  later  stages 

Frequency  band  RMS 

Increasing  in  later  stages  with  high  and  decreasing  kurtosis 

Bearing  Inner  Race  Fault 

EnvPS  RPIR  defect  frequency  energy 

Presence 

EnvPS  RPIR  harmonics  energy 

Presence 

EnvPS  shaft  SB  energy  around  RPIR 

Presence;  total  of  1st  4  orders  approaching,  exceeding  fundamental 

EnvPS  shaft  SB  energy  around  RPIR  1st 
harmonic 

Presence;  total  of  lsl  4  orders  approaching,  exceeding  fundamental 

EnvPS  shaft  frequency  energy 

Increase  above  baseline 

EnvPS  shaft  harmonics  energy 

Total  of  1st  3  harmonics  increasing  above  baseline 

Baseband  lx  RPIR  defect  frequency 

Presence 

Cepstral  rahmonic  at  shaft  period 

Increase  trend  above  baseline 

Frequency  band  kurtosis 

Above  variance,  growing  -early:  Above  and  decreasing  -  late 

Frequency  band  noise  floor 

Increasing  in  later  stages 

Frequency  band  RMS 

Increasing  in  later  stages  with  high  and  decreasing  kurtosis 
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Table  24  Rolling  Element  and  Cage  Bearing  Faults 


Fault  /  Enhanced  Features 

Fault  Symptoms 

Bearing  Rolling  Element  Fault 

EnvPS  2xRSPIN  defect  frequency  energy 

Presence 

EnvPS  2xRSPIN  harmonics  energy 

Presence 

EnvPS  cage  SB  energy  around  2xRSIN 

Presence;  total  of  1st  4  orders  approaching,  exceeding 
fundamental 

EnvPS  cage  SB  energy  around  2xRSPIN  1st 
harmonic 

Presence;  total  of  1st  4  orders  approaching,  exceeding 
fundamental 

EnvPS  cage  frequency  energy 

Presence,  increasing  with  severity 

EnvPS  cage  harmonics  energy 

Presence,  increasing  with  severity 

Baseband  2xRSPIN  defect  frequency 

Presence 

Baseband  lx  cage  rev  frequency 

Presence 

Baseband  cage  harmonics 

Presence 

Cepstral  rahmonic  at  cage  period 

Presence,  increase 

Frequency  band  kurtosis 

Frequency  band  noise  floor 

Increasing  in  later  stages 

Frequency  band  RMS 

Increasing  in  later  stages  with  high  and  decreasing  kurtosis 

Bearing  Cage  Fault 

Presence,  increasing  with  severity 

EnvPS  cage  harmonics  energy 

Presence,  increasing  with  severity 

Baseband  lx  cage  rev  frequency 

Presence 

Baseband  cage  harmonics 

Presence 

Cepstral  rahmonic  at  cage  period 

Presence 

Frequency  band  kurtosis 

Increasing  in  later  stages 

Frequency  band  noise  floor 

Increasing  in  later  stages 

Frequency  band  RMS 

Increasing  in  later  stages 
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4.2.5.23  Gear  and  Shaft  Health  Monitoring 

The  processing  of  gear  vibration  signals  used  to  extract  vibration  related  features  in 
shown  in  Figure  63.  The  raw  time- domain  signals  are  first  calibrated  (not  shown  in  the 
figure),  then  the  signal  statistics  are  calculated  and  FFTs  of  the  signals  are  computed.  The 
physical  dimensions  and  characteristics  of  the  gears  and  shafts  are  used  to  compute  defect 
frequencies.  The  signal  spectrum  is  searched  for  narrowband  energy  at  the  defect 
frequencies  as  indicators  of  potential  gear  or  shaft  faults.  If  energy  is  present  at  related 
defect  frequencies,  additional  processing  is  performed  to  extract  potential  features. 

One  form  of  additional  processing  is  the  computation  of  the  cepstrum  from  the  signal 
spectrum.  Cepstral  rhamonics  (the  cepstral  equivalent  of  a  frequency  response  harmonic) 
at  the  associated  rotational  period  is  one  indicator  of  damage.  Time- synchronous 
averaging  is  a  widely  used  technique  for  removing  unwanted  or  uncorrelated  vibration 
energy  from  the  measured  signal.  After  time- synchronous  averaging,  the  averaged  signal 
can  be  processed  in  either  the  time  or  frequency  domain.  The  figure  above  only  shows 
time -domain  processing  of  the  time- synchronous  averaged  signal.  Statistical  measures 
such  as  kurtosis  applied  to  bandpass  filtered  or  residual  signals  are  often  used  as  features. 
The  residual  signal  has  the  mesh  frequency  and  harmonics  removed  from  the  measured 
signal,  thereby  revealing  low-level  signals  related  to  the  progressing  damage. 


Gears  Reduction  Gear  Box.  Accessory  Gear  Box  It  HM  -3.  ^4 

Shafts  -  Generator.  Reduction  Geat  Box  Accessors  Gear  Box  ICHM  t:2.  -3.  "4 


Figure  63  Extraction  of  Gear  and  Shaft  Vibration  Features 

After  computing  the  vibration  related  features,  a  Kalman  filter  is  used  to  smooth  the 
feature  tracks  and  predict  the  future  feature  values  within  the  alert  time  threshold.  The 
processed  features  are  then  passed  to  the  fuzzy- logic  classifier  to  determine  gear  and 
shaft  fault  confidences  as  shown  in  Figure  64.  In  the  case  of  bearings,  temperature  data 
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can  be  used  to  correlate  damage  to  the  component.  Temperature  data  typically  has  less 
value  in  gear  monitoring  due  to  the  relatively  small  contact  area  between  components 
compared  to  bearings.  In  cases  where  accelerometers  are  installed  in  locations  with  high 
operating  temperatures,  temperature  measurements  can  be  used  to  assess  potential  sensor 
problems  (e.g.  changes  in  sensor  sensitivity  due  to  elevated  operating  temperature).  All 
processing  can  be  performed  at  the  ICHM  level.  When  the  ICHM  monitors  several 
vibration  sensors,  the  signals  from  the  different  sensors  can  be  correlated  to  increase  or 
decrease  the  confidence  in  the  fault  assessment  or  to  identify  potential  sensor  problems. 


Gear  and  shaft 
Vibration 
Features 


Gear  and  shaft  faults 

_ ^ 


Reduction  Gear  Box  ICHM  ICHM  #3 

Accessor}'  Gearbox  ICHM  ICHM  #4 

Figure  64  Gear  and  Shaft  Fault  Processing 


Table  25  below,  shows  features  and  symptoms  for  different  types  of  gear-related  faults. 
In  general,  a  fault  with  a  particular  component  is  indicated  by  a  change  in  energy  at  a 
defect  frequency  related  to  the  geometry  of  the  particular  component. 

Table  25  Gear  and  Drive  Related  Faults 


Fault  /  Enhanced  Features 

Fault  Symptoms  ! 

Above  variance,  growing  -earlv.  Above  and  decreasing  -  advanced  i 

LCenstral  rahmonic  at  shaftperiod _ 

increasing  with  tooth  breakage,  leveling  off  until  next  breakage  1 

Increasing  with  advanced  deterioration 

Gear  mesh  level 

No  significant  increase 

Gear  Wear  Fault 

Enhanced  kurtosis  (from  residual) 

Stays  around  3.0 

Gear  mesh  level 

Significant  increase 

RMS  level 

Increase  with  severity 

Drive  Shaft  Fault 

RMS  level 

Gradual  continuing  increase 

-Shaft  1st  and  2nd  order  SB’s  around  gear  mesh 

Baseband  shaft  harmonic  strength 

1  Significantly  increasing  1 

\bli  At  *  Ai  ktuti  tt  m  1 1  lA  IIsIjMi  1 
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4.2.5.2.4  Reduction  Gear  Box  Processing 

Figure  65  shows  the  processing  flow  of  the  reduction  gearbox  ICHM.  Vibration  data  is 
processed  using  the  bearing  and  gear  health  monitoring  approaches  described  previously 
(sections  42.5.2.2  and  4.2.5.23),  and  then  fused  with  available  temperature  information 
to  improve  the  confidence  in  identified  bearing  faults. 
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Figure  65  RBG  Processing  Flow 


4. 2. 5. 2. 5  Accessory  Gear  Box  Processing 

After  computing  the  vibration  related  features,  a  Kalman  filter  is  used  to  smooth  the 
feature  tracks  and  predict  the  future  feature  values  within  the  alert  time  threshold.  The 
processed  features  are  the  n  passed  to  the  fuzzy-  logic  classifier  to  determine  gear  and 
shaft  fault  confidences  -  Figure  66.  In  the  case  of  bearings,  temperature  data  can  be  used 
to  correlate  damage  to  the  component.  Temperature  data  typically  has  less  value  in  gear 
monitoring  due  to  the  relatively  small  contact  area  between  components  compared  to 
bearings.  In  cases  where  accelerometers  are  installed  in  locations  with  high  operating 
temperatures,  temperature  measurements  can  be  used  to  assess  potential  sensor  problems 
(e.g.  changes  in  sensor  sensitivity  due  to  elevated  operating  temperature).  All  processing 
can  be  performed  at  the  ICHM  level.  When  the  ICHM  monitors  several  vibration  sensors, 
the  signals  from  the  different  sensors  can  be  correlated  to  increase  or  decrease  the 
confidence  in  the  fault  assessment  or  to  identify  potential  sensor  problems. 


152 


NSWCCD-TR-2003/02 


Accelerometer 


Gear  and 
shaft  faults 


Increase  or 
decrease 
confidence  in 
gear  faults 

Sensor 

confidence 


j 


ICHM  ICHM  or  SHM  depending  on 

source  of  temp  data 
(@  ICHM  for  RSVP  system) 


Figure  66  AGB  Processing  Flow 


4,2.53  Data  Processing  and  Analysis 


4. 2. 5. 3. 1  Approach/Software  Structure 

Several  feature  extraction  techniques  were  implemented  on  the  four  SSGTG  subsystems 
monitored  by  the  Machinery  Health  Monitoring  System,  These  feature  extraction 
techniques  were  developed  by  the  Condition- Based  Maintenance  Department  at  Penn 
State  ARL  as  part  of  the  Condition-Based  Maintenance  (CBM)  Features  Toolbox.  In 
addition  to  the  analysis  techniques,  the  Toolbox  software  structure  and  processing 
approach  was  adopted  by  the  Integrated  Component  Health  Monitors  used  in  the  RSVP 
ATD,  The  following  description  is,  for  the  most  part  taken  directly  from  the  CBM 
Features  Toolbox  User’s  Guide. 

The  Condition-Based  Maintenance  (CBM)  Features  toolbox  is  a  conglomeration  of 
traditional  features  discussed  in1  along  with  a  few  non-traditional  features  developed  at 
ARL.  Developed  in  Matlab  the  toolbox  provides  a  set  of  standard  processing  routines  to 
help  perform  machinery  diagnostics  and  prognostics.  Toolbox  flexibility  supports  the 
addition  of  features  and  input/output  data  file  formats.  By  using  an  INI  file  interface,  the 
user  can  easily  change  analysis  parameters  and  process  data  with  one  Matlab  command. 


1  Lebold,  M.,  McClintic,  K.,  Campbell,  R.,  Byington,  C,,  Maynard,  K,,  ’’Review  of  Vibration  Analysis 
Methods  for  Gearbox  Diagnostics  and  Prognostics”,  54th  Meeting  of  the  MFPT,  Virginia,  May  2000. 
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The  user  may  also  pass  data  directly  into  any  of  the  individual  stand-alone  feature 
routines.  The  CBM  INI  file  is  a  text  file  format  that  stores  parameters  and  information 
about  the  accelerometers,  signal  conditioning,  preprocessing  parameters  and  the  feature 
parameters.  The  flowchart  in  Figure  67  shows  the  data  flow  into  and  out  of  the  CBM 
toolbox.  To  ensure  that  there  are  no  issues  on  how  the  data  was  processed  all  of  the 
parameters  and  information  stored  in  the  INI  file  are  placed  in  the  output  data  file  along 
with  the  feature  data. 


Output  Data  File: 
•Feature  Matrix 
•Feature  Names 

•  Feature  Units 

•  INI  Parameters 


Output  Data  File: 
Feature  Matrix 
Feature  Names 
Feature  Units 
INI  Parameters 


Figure  67  Inputs  and  Output  of  the  CBM  Toolbox 


Eight  (8)  CBM  Toolkit  feature  processing  routines  resulting  in  Figures  Of  Merit  (FOM) 
were  implemented  in  the  RSVP  HMS.  Feature  functions  can  produce  multiple  FOMs  and 
be  calculated  in  multiple  preprocessing  categories.  The  features  and  FOMs  implemented 
on  the  Integrated  Health  Component  Monitors  in  RSVP  are  identified  in  Table  26.  All  of 
the  analysis  features  and  input/output  data  files  are  controlled  via  a  single  command  line 
to  support  batch  processing. 
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Table  26  Feature  functions,  the  resultant  FOMs,  categorized  by  preprocessing  level 


Function 
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4.2. 5. 3. 2  Feature  Extraction  Overview 

Many  types  of  defects  or  damage  will  increase  the  machinery  vibration  levels.  These 
vibration  levels  are  then  converted  to  electrical  signals  for  data  measurement  by 
accelerometers.  In  principle,  the  information  concerning  the  health  of  the  monitored 
machine  is  contained  in  this  vibration  signature.  Hence,  the  new  or  current  vibration 
signatures  could  be  compared  with  previous  signatures  to  determine  whether  the 
component  is  behaving  normally  or  exhibiting  signs  of  failure.  In  practice,  such 
comparisons  are  not  effective.  Due  to  the  large  variations,  direct  comparison  of  signatures 
is  difficult.  Instead,  a  more  useful  technique  that  involves  the  extraction  of  features  from 
the  vibrational  signature  data  could  be  used.  Ideally,  these  features  are  more  stable  and 
well  behaved  than  the  raw  signature  data  itself.  Features  also  provide  a  reduced  data  set 
for  the  application  of  pattern  recognition  and  tracking  techniques. 

Before  any  feature  can  be  calculated  on  the  raw  vibration  data,  the  data  must  be 
conditioned  or  preprocessed.  Conditioning  may  range  from  signal  correction,  based  on 
the  data  acquisition  unit  and  amplifiers  used,  and  mean  value  removal  to  time- 
synchronous  averaging  and  filtering.  A  variety  of  signal  processing  techniques  are  used 
based  on  the  feature  being  implemented.  The  features  are  divided  into  five  preprocessing 
categories:  1)  Raw  signal  (RAW),  2)  Time  synchronous  averaged  signal  (TSA),  3) 
Residual  signal  (RES),  4)  Difference  signal  (DIF),  and  5)  Band-pass  mesh  signal  (BPM). 
The  traditional  processing  flow  for  CBM  feature  extraction  methods  is  shown  in  Figure 
68.  It  is  important  to  note  that  what  is  optimal  for  the  one  piece  of  equipment/ 
configuration,  may  not  be  optimal  for  other  gearboxes  or  faults,  and  the  INI  file  can  be 
used  to  set  the  appropriate  preprocessing  parameters.  Adjustment  of  these  parameters  for 
the  SSGTG  was  accomplished  after  collection  of  data  at  the  LBES 
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The  RAW  preprocessing  denotes  features  that  are  calculated  from  the  raw  or  conditioned 
signal  from  the  sensor.  The  only  preprocessing  needed  for  these  features  is  conditioning 
the  signal  or  removing  the  mean  of  the  signal.  Signal  conditioning  is  simply  multiplying 
all  of  the  data  points  by  some  calibration  constant  that  is  based  on  the  accelerometer  and 
amplifier  used.  The  features  in  this  group  are:  RMS,  Kurtosis,  Crest  Factor,  and 
Enveloping. 

The  TSA  preprocessing  entails  time  synchronous  averaging  of  the  raw  data.  Time 
synchronous  averaging  is  a  signal  processing  technique  that  is  used  to  extract  repetitive 
signals  from  additive  noise.  This  process  requires  an  accurate  knowledge  of  the  repetitive 
frequency  of  the  desired  signal  or  a  signal  that  is  synchronous  with  the  desired  signal. 

The  raw  data  is  then  divided  up  into  segments  of  equal  length  blocks  related  to  the 
synchronous  signal  and  averaged  together.  When  sufficient  averages  are  taken,  the 
random  noise  is  canceled,  leaving  an  improved  estimate  of  the  desired  signal.  Before  the 
signal  is  segmented,  the  number  of  data  points  in  the  series  is  increased  by  means  of 
interpolation.  This  will  provide  a  closer  approximation  when  the  signal  is  segmented  and 
averaged.  The  sensor  signal  is  segmented  based  on  the  synchronous  signal.  For  example, 
a  tachometer  signal  can  be  used  as  a  synchronous  signal  for  rotating  machinery.  Each 
segment  will  start  based  on  the  leading  edge  of  a  tach  pulse  and  end  on  the  corresponding 
data  point  that  precedes  the  next  tach  pulse.  Because  of  slight  speed  changes  over  the 
sample  and  inaccuracies  in  the  tach  pulse,  the  number  of  points  in  each  segment  might 
vary  slightly.  One  method  that  has  been  used  is  to  pick  the  segment  with  the  lowest 
number  of  points  and  only  average  over  this  length.  This  may  be  thought  of  as  justifying 
the  data  to  the  left  and  clipping  off  the  data  beyond  the  averaging  length.  The  last  step  is 
to  average  all  of  the  segments  and  decimate  back  to  the  original  sampling  rate. 

There  are  three  parameters  involved  with  TSA  that  can  affect  the  results:  the  interpolation 
factor,  the  number  of  revolutions  concatenated  together  during  the  alignment,  and  the 
number  of  averages.  Lebold,  et  al1  describes  these  preprocessing  parameters  in  more 
detail,  and  McClintic,  et  al2  shows  how  these  parameters  affect  the  residual  and 
difference  analysis  features  when  processed  on  Mechanical  Diagnostics  Test  Bed 
(MDTB)  data.  A  detailed  description  of  the  Applied  Research  Laboratory’s  MDTB  can 
be  found  in  reference 

The  RES  preprocessing  calculates  the  residual  signal,  which  consists  of  the  time 
synchronous  averaged  signal  with  the  primary  meshing  and  shaft  components  along  with 
their  harmonics  removed.  What  is  unclear  from  the  literature  is  how  many  harmonics  to 
remove  for  the  primary  mesh  and  shaft  components.  For  a  time  synchronous  averaged 


1  Lebold,  M.,  McClintic,  K.,  Campbell,  R.,  Byington,  C.,  Maynard,  K.,  ’’Review  of  Vibration  Analysis 
Methods  for  Gearbox  Diagnostics  and  Prognostics”,  54th  Meeting  of  the  MFPT,  Virginia,  May  2000. 

2  McClintic,  K.,  Lebold,  M.,  Maynard,  K.,  Byington,  C.,  Campbell,  R.,  “Residual  and  Difference  Feature 
Analysis  with  Transitional  Gearbox  Data  ”,  54th  Meeting  of  the  MFPT,  Virginia,  May  2000. 

3Byington,  C.S.,  Kozlowski,  J.D.,  “Transitional  Data  for  Estimation  of  Gearbox  Remaining  Useful  Life  ”, 
5 1st  Meeting  of  the  Society  for  Machinery  Failure  Prevention  Technology  (MFPT),  April  1997. 
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data  over  one  revolution,  this  means  that  the  smallest  resolution  in  the  frequency  domain 
is  the  shaft  frequency.  Therefore,  this  would  mean  removing  every  point  in  the  spectrum. 
What  has  shown  to  produce  favorable  results  is  to  high  pass  the  data  about  some 
frequency  and  only  remove  the  meshing  frequency  and  all  harmonics.  The  cut-off 
frequency  of  the  high  pass  filter  will  be  system  dependent,  but  it  should  lie  somewhere 
between  DC  and  the  fundamental  meshing  frequency.  Also,  removal  of  five  mesh 
harmonics  has  produced  results  very  similar  to  the  results  produced  by  removing  all  the 
harmonics,  but  this  may  be  system  dependent. 
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Figure  68  Traditional  Processing  Flow  for  CBM  Feature  Extraction  Methods 

The  DIF  preprocessing  section  calculates  the  difference  signal  by  removing  the  regular 
meshing  components  from  the  time  synchronous  averaged  signal.  The  regular  meshing 
components  consist  of  the  shaft  frequency  and  its  harmonics,  die  primary  meshing 
frequency  and  harmonics  along  with  the  first  order  sidebands.  Since  the  residual  signal  is 
the  result  of  removing  the  primary  meshing  and  shaft  frequencies  and  harmonics,  the  DIF 
processing  section  can  consist  of  removing  only  the  sidebands  of  the  primary  meshing 
frequencies  from  the  RES  signal.  Assuming  that  a  high-pass  filter  or  a  limited  number  of 
shaft  frequency  harmonics  were  removed,  this  will  mean  that  only  the  sidebands  of  the 
meshing  frequency  and  its  harmonics  need  to  be  removed.  For  the  case  where  time 
synchronous  averaging  is  performed  over  one  revolution,  the  sidebands  will  be  one  bin 
on  either  side  of  the  meshing  frequency.  The  features  in  the  DIF  group  are:  FM4,  M6A, 
and  M8  A. 
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4.2.53.3  Feature  Extraction  Techniques  Description 


4.2.5.3.3.1  RMS 


The  root  mean  square  (RMS)  value  of  a  vibration  signal  is  a  time  analysis  feature  that  is 
the  measure  of  the  power  content  in  the  vibration  signature.  This  feature  is  good  to  track 
the  overall  noise  level,  but  it  will  not  provide  any  information  on  which  component  is 
failing.  It  can  be  very  effective  in  detecting  a  major  out-of-balance  in  rotating  systems. 
Below  is  the  equation  that  is  used  to  calculate  the  root  mean  square  value  of  a  data  series, 
x„  over  length  N. 


RMS  = 


(1) 


4.2.5.3.3.2  Kurtosis 

Kurtosis  is  defined  as  the  fourth  moment  of  the  distribution  and  measures  the  relative 
peakedness  or  flatness  of  a  distribution  as  compared  to  a  normal  distribution.  Kurtosis 
provides  a  measure  of  the  size  of  the  tails  of  distribution  and  is  used  as  an  indicator  of 
major  peaks  in  a  set  of  data.  As  a  gear  wears  and  breaks  this  feature  should  react  to  the 
increased  level  of  vibration  [1].  The  equation  for  kurtosis  is  given  by: 

t  iL ly{n)~rf  <2) 

N*(c 72)2 

where  y (n)  is  the  raw  time  series  at  point  n,  p  is  the  mean  of  the  data,  o2  is  the  variance  of 
the  data,  and  N  is  the  total  number  of  data  points. 


4.2.5.3.3.3  Crest  Factor 

The  simplest  approach  to  measuring  defects  in  the  time  domain  is  using  the  RMS 
approach.  However,  the  RMS  level  may  not  show  appreciable  changes  in  the  early  stages 
of  gear  and  bearing  damage.  A  better  measure  is  to  use  “crest  factor”  which  is  defined  as 
the  ratio  of  the  peak  level  of  the  input  signal  to  the  RMS  level.  Therefore,  peaks  in  the 
time  series  signal  will  result  in  an  increase  in  the  crest  factor  value.  For  normal 
operations,  crest  factor  may  reach  between  2  and  6.  A  value  above  6  is  usually  associated 
with  machinery  problems.  This  feature  is  used  to  detect  changes  in  the  signal  pattern  due 
to  impulsive  vibration  sources  such  as  tooth  breakage  on  a  gear  or  a  defect  on  the  outer 
race  of  a  bearing.  The  crest  factor  feature  is  not  considered  a  very  sensitive  technique. 
Below  is  the  equation  for  the  crest  factor: 


_  ^  PeakLevel 

Crest  Factor  = - 

RMS 


(3) 


where  PeakLevel  is  the  peak  level  of  the  raw  time  series,  and  RMS  is  the  root  mean 
square  of  the  raw  data. 
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4.2.5.3.3.4  Enveloping 

Enveloping  is  used  to  monitor  the  high-frequency  response  of  die  mechanical  system  to 
periodic  impacts  such  as  gear  or  bearing  faults.  An  impulse  is  produced  each  time  a 
loaded  rolling  element  makes  contact  with  a  defect  on  another  surface  in  the  bearing  or  as 
a  faulty  gear  tooth  makes  contact  with  another  tooth.  This  impulse  has  an  extremely  short 
duration  compared  to  the  interval  between  the  pulses.  The  energy  from  the  defect  pulse 
will  be  distributed  at  a  very  low  level  over  a  wide  range  of  frequencies.  It  is  this  wide 
distribution  of  energy  that  makes  bearing  defects  so  difficult  to  detect  by  conventional 
spectrum  analysis  when  they  are  in  the  presence  of  vibrations  from  gears  and  other 
machine  components.  Fortunately,  the  impact  usually  excites  a  resonance  in  the  system  at 
a  much  higher  frequency  than  the  vibration  generated  by  the  other  components.  This 
structural  energy  is  usually  concentrated  into  a  narrow  band  that  is  easier  to  detect  than 
the  widely  distributed  energy  of  the  bearing  defect  frequencies.  With  tooth  wear  and 
breakage,  the  side  band  activity  near  critical  frequencies  such  as  the  output  shaft 
frequency  is  expected  to  increase.  The  entire  spectrum  contains  very  high  periodic  signals 
associated  with  the  gear  mesh  frequencies. 

The  envelope  or  high  frequency  technique  focuses  on  the  structure  resonance  to 
determine  the  health  of  a  gear  or  the  type  of  failure  in  a  bearing.  This  technique  consists 
of  processing  structure  resonance  energy  with  an  envelope  detector.  The  structure 
resonance  is  obtained  by  band -pass  filtering  the  data  around  the  structure  resonance 
frequency.  The  band-pass  filtered  signal  is  then  processed  by  an  envelope  detector,  which 
consists  of  a  half-wave  (or  full- wave)  rectifier  and  a  peak-hold  and  smoothing  section.  A 
simple  envelope  detector  processing  flow  diagram  is  shown  in  Figure  69. 
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Figure  69  Simple  Envelope  Detector  Scheme 

The  center  frequency  of  the  band -pass  filter  should  be  selected  to  coincide  with  the 
structure  resonance  frequency  being  studied.  The  bandwidth  of  the  filter  should  be  at 
least  double  the  highest  characteristic  defect  frequency.  This  will  ensure  that  the  filter 
will  pass  the  carrier  frequency  and  at  least  one  pair  of  modulation  sidebands.  In  practice, 
the  bandwidth  should  be  somewhat  greater  to  accommodate  the  first  two  pairs  of 
modulation  sidebands  around  the  carrier  frequency. 

The  rectifier  in  the  envelope  detector  turns  the  bipolar  filtered  signal  into  a  unipolar 
waveform.  The  peak-hold  smoothing  section  will  then  remove  the  carrier  frequency  by 
smoothing/filtering  the  fast  transitions  in  the  signal.  The  remaining  signal  will  then 
consist  of  the  defect  frequencies. 
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This  feature  produces  several  figures  of  merit  for  analysis  use.  The  primary  figure  of 
merit  is  the  peak  frequency  and  amplitude  in  the  power  spectral  density  of  the  enveloped 
data.  Other  figures  of  merit  include  the  RMS  and  kurtosis  values  of  the  filtering  section 
and  the  standard  deviation  of  the  output  from  the  rectification  and  smoothing  block. 

The  envelope  technique  has  been  widely  used  in  numerous  applications  and  has  shown 
successful  results  in  the  early  detection  of  bearing  faults.  Besides  early  detection,  this 
process  can  help  distinguish  the  actual  cause  of  bearing  failure  by  inspecting  the  actual 
bearing  defect  frequencies. 


4.2.5.3.3.5  FM4 


FM4  was  developed  to  detect  changes  in  the  vibration  pattern  resulting  from  damage  on  a 
limited  number  of  gear  teeth  [2].  FM4  is  calculated  by  applying  the  fourth  normalized 
statistical  moment  to  this  difference  signal  as  given  in  the  equation: 


FM  4  = 


(9) 


where  d  is  the  difference  signal,  d  is  the  mean  value  of  difference  signal,  and  N  is  the 
total  number  of  data  points  in  the  time  record.  A  difference  signal  from  a  gear  in  good 
condition  will  be  primarily  Gaussian  noise  therefore  resulting  in  a  normalized  kurtosis 
value  of  3.  As  a  defect  develops  in  a  tooth,  peaks  will  grow  in  the  difference  signal  that 
will  result  in  the  kurtosis  value  to  increase  beyond  3. 


4.2.5.3.3.6  M6A  and  M8A 

M6A  and  M8A  were  proposed  by  Martin4  to  detect  surface  damage  on  machinery 
components.  Both  of  these  features  are  applied  to  the  difference  signal.  The  theory 
behind  M6A  and  M8A  is  the  same  as  that  for  FM4,  except  that  M6A  and  M8A  are 
expected  to  be  more  sensitive  to  peaks  in  the  difference  signal.  The  equations  for  M6A 
and  M8A  are  as  follows: 


i=i 


where  d  is  the  difference  signal,  d  is  the  mean  value  of  difference  signal,  and  N  is  the 
total  number  of  data  points  in  time  record. 


4  Martin,  H.  R.,  “Statistical  Moment  Analysis  As  a  Means  of  Surface  Damage  Detection”,  Proceedings  of 
the  7th  International  Modal  Analysis  Conference,  Society  for  Experimental  Mechanics,  Schenectady,  NY, 
1989,  pp.  1016-1021. 
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Figure  70  RSVP  Personnel  Status  Monitoring  Belt 

The  chest  belt  (Figure  70)  is  always  on  unless  the  battery  has  run  down  (estimated  life 
3  months)  or  removed.  For  the  first  belt  unit,  the  accelerometer  must  be  recalibrated 
when  the  battery  is  replaced.  The  unit  is  initialized  by  hanging  "vertically  from  one 
end  as  the  battery  is  inserted  and  held  that  way  for  >60  seconds.  (In  this  position, 
gravity  will  have  no  biasing  effect  on  the  accelerometer.)  For  the  rest  of  the  belts,  no 
calibration  is  required  when  replacing  the  batteries.  (Calibration  constants  were 
measured  and  stored  in  the  Belt’s  nonvolatile  memory.) 

The  ISU  is  worn  across  the  chest  with  the  long  (two  (rubber)  electrodes  on  the  left 
side  of  the  body.  The  belt  should  be  under  the  pectoral  muscles  and  the  end  of  the 
long  arm  in/below  the  left  armpit  (axilla).  Electrode  contact  is  enhanced  by  sweat  or 
ECG  electrode  conductive  gel.  Excessive  body  hair  may  form  a  bad  electrode  contact. 
The  belt  should  fit  snugly. 

The  SARCOS  logo  is  on  the  battery  door.  That  door  is  bayonet  mounted,  rotate  1/8 
turn  or  so  anticlockwise  and  lift.  There  is  an  “O”  ring  seal  for  the  door.  The 
replacement  cell  is  a  CR2477N.  Battery  is  inserted  with  the  “+”  facing  down. 

The  ISU  measures  axillary  temperature,  shivering,  position,  motion,  &  heart  rate 
derived  from  ECG  signal.  The  short-range  magnetic  link  to  the  CIU  has  a  maximum 
range  of  1  meter  but  depending  on  transmitting  (ISU)  and  receiving  (CIU)  coil 
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orientation  that  range  may  be  reduced  to  about  30  cm.  The  ISU  transmits  a  packet 
every  15  seconds. 

4.3.2  CIU  (Waist  belt  unit) 


Figure  71  RSVP  RF-Communication  Interface  Unit 

The  CIU  (Figure  71)  receives  the  ISU  Bodylan  packets,  processes  the  ISU  data,  adds 
local  information  such  as  the  CIU’s  temperature  and  relays  data  to  the  radio  via  the 
SPI  interface.  CIU  operates  in  following  modes: 

1 .  Standby  (message  82)  CIU  does  not  signal  radio 

2.  15  second  update  (message  84*)  CIU  signals  radio  every  15  seconds 
independent  of  ISU  Packet 

3.  60  second  update(message  81)  CIU  signals  radio  every  60  second  independent  of 
ISU  Packet 

4.  On  ISU  packet  CIU  signals  radio  only  on  reception  of  ISU  packet 

In  the  1 5  and  60  second  modes,  the  CIU  will  signal  the  radio  with  or  without  reception  of 
a  ISU  packet.  Since  these  two  operations  are  asynchronous  two  each  other,  data  may  be 
delayed  by  one  CIU  packet  cycle. 

There  are  3  status  LEDs  on  the  CIU  Processor  board.  These  are  meant  for  quiet  (visual) 
diagnostics.  They  are: 

Green  -  SPI  active. 

Normally  this  LED  will  flash.  The  CIU  turns  this  on  when  it  signals  the  Radio 
(SPI  Master)  that  it  has  a  packet  of  data  to  send.  The  CIU  turns  it  off  when  it  is 
finished  with  sending  data  to  the  Radio. 

Yellow  LED  -  Bodylan  Power. 

This  LED  is  powered  by  the  same  power  running  the  Bodylan  receiver 
electronics.  When  the  CIU  is  first  powered  on,  the  Bodylan  circuitry  is  powered 
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up  looking  for  a  valid  ISU  packet.  It  will  remain  on  until  the  CIU  receives  a  valid 
ISU  packet.  Once  a  valid  packet  is  received,  the  CIU  will  synchronize  its  internal 
clock  and  power  down  the  Bodylan  electronics.  If  the  CIU  is  in  the  15  second 
mode,  it  will  power  up  the  Bodylan  circuitry  1  second  prior  to  receiving  an 
expected  ISU  packet.  If  the  CIU  doesn’t  see  any  ISU  packet  (good  or  bad)  it  will 
power  down  and  look  again  at  the  next  expected  ISU  packet  time.  If  the  CIU  fails 
to  see  ISU  packets  four  consecutive  times,  it  will  leave  the  Bodylan  powered  on. 

Red  LED  -  ISU  Packet  Error. 

This  LED  indicates  the  ISU  packet  was  received  with  error(s).  The  CIU  measures 
both  the  number  of  pulses  and  the  duration  between  pulses  in  order  to  determine 
the  values  being  sent.  If  a  pulse  is  missing  or  the  timing  is  incorrect,  it  will  throw 
the  packet  out  &  light  the  Red  LED.  When  this  occurs,  the  Bodylan  circuitry  will 
remain  on  until  it  does  receive  a  valid  packet  and  the  Red  LED  will  also  stay  lit. 

The  CIU  Black  Box  contains  the  CIU  processor  board  (and  battery  package),  Radio 
board,  and  Antenna  board.  The  boards  are  stacked  together  with  the  Antenna  board 
facing  the  opposite  side  of  the  belt  clip.  The  CIU  processor  board  (middle  of  the  stack) 
has  the  battery  package.  The  CIU  operates  using  3  AAA  batteries.  In  order  to  gain  access, 
the  cover  and  the  Antenna,  must  be  removed. 

Switches 

There  are  two  switches  for  the  CIU,  These  are: 

Power  Switch 

This  is  the  main  power  switch  and  is  located  on  the  top  side  of  the  CIU  box.  On  is 
towards  the  center  of  the  box.  When  initially  turned  on,  the  Red  and  Green  LEDs 
will  flash  4  times,  then  with  the  Yellow  LED  staying  on  indicating  the  CIU  is 
searching  for  an  ISU  packet.  (The  internal,  on-board  pushbutton  switch  is  wired  in 
parallel  with  the  slider  switch.) 

Help  Switch 

This  a  button  mounted  on  the  CUI  Processor  board,  A  small  extension  has  been 
added  to  bring  the  actuator  flush  with  the  surface  of  the  lid.  Pressing  this  will 
signal  the  CIU  (via  interrupt)  that  the  user  has  requested  help.  Pushing  the  HELP 
button  will  force  the  CIU  into  the  1 5  second  mode  for  4  cycles.  It  will  set  a  bit  in 
one  of  the  status  registers  (help  flag  bit)  as  well  as  setting  the  Sailor  Status  to 
RED.  The  CIU  will  send  this  status  4  consecutive  times  then  clear  the  Help  flag. 
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4.4  Access  Point 
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Figure  72  Access  Point  Hardware 


4.4.1  Hardware 

An  AP  is  an  industrial  grade  IBM- clone  PC  running  the  Embedded  Windows  NT 
operating  system.  An  illustration  of  an  AP  is  shown  Figure  72.  Each  AP  consists  of 
widely  available  components,  ruggedized  for  shipboard  use.  They  operate  off  of  ship’s 
power.  Each  Access  Point  will  incorporate  the  follow  accessory  hardware  items: 

1 .  Video  camera  with  audio 

2.  Video  capture  card 

3 .  Ethernet  card  ( 1 00B  aseT) 

4.  3.5”  floppy  drive 

5.  CD-ROM  writer  drive 

6.  2.2  GB  EIDE  removable  media  drive 

7.  Integral  keyboard  and  LCD  display 

APs  perform  data  logging  and  maintain  a  video  loop  recorder.  Individual  Access  Points 
transmit  real-time  video  or  recorded  video  as  commanded  via  the  backbone.  For  sensed 
data,  Access  Points  within  a  particular  space  exchange  data  with  each  other  so  each  can 
make  decisions  based  on  all  the  data  in  the  space.  A  COTS  software  package,  NDDS 
(Network  Data  Delivery  Service),  have  been  selected  as  communication  middleware. 
NDDS  provides  data/  information  exchange  and  development  environments  between  the 
environmental  and  structural  sensors  clusters,  the  Machinery  Health  Monitoring  System 
and  the  Access  Point  and  the  Watchstation. 
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4.4.2  Software  System  and  Development 

Within  a  compartment,  a  LAN  connects  the  Access  Points  (APs).  Every  Access  Point  is 
connected  to  a  radio  receiver  via  a  serial  line.  In  turn,  the  radio  receiver  connects  to  RF 
Sensor  Cluster  transmitters.  All  of  the  APs  share  identical  software.  However,  one  AP  is 
identified  as  the  “Primary”  AP  and  has  the  additional  responsibility  of  communicating 
with  the  Watch  Station. 

The  principle  of  “Reliability  Through  Redundancy”  extends  to  the  AP  software.  All  of 
the  Sensor  Cluster  data  must  be  available  at  every  AP.  Should  RSVP  lose  an  AP,  the 
sensor  cluster  data  should  still  be  available,  and  other  APs  should  shoulder  the 
responsibility  of  the  lost  unit. 

The  state  of  a  compartment  is  the  sum  of  the  information  from  all  of  the  sensor  clusters  in 
the  compartment.  However,  the  radio  receiver  connected  to  an  AP  only  receives 
communication  from  a  few  sensor  clusters.  Sensor  cluster  information,  and  indeed  all  AP 
state  information,  needs  to  be  shared  among  all  APs.  Every  AP  needs  to  know  the  state  of 
its  peers,  and  the  state  of  the  compartment  at  all  times.  RSVP  requires  continuous  and 
ubiquitous  communication. 

The  two  traditional  LAN  communication  paradigms:  client/server  communication,  point- 
to-point  communication  were  investigated  and  rejected  in  favor  of  a  publish/subscribe 
methodology.  Publish/subscribe  is  built  on  client/server  and  point-to-point 
communication,  but  the  lower  level  communication  details  are  hidden.  Since  the 
communication  details  are  hidden  the  developers  can  focus  on  substantive  application 
matters. 

4.4.2.1  Publish/Subscribe  Paradigm 

The  client/server  model  is  appropriate  when  multiple  clients  need  to  communicate  with  a 
central  server.  The  RSVP  communication  requirement  could  be  addressed  from  the 
client/server  model  if  every  AP  was  considered  both  a  client  accepting  connecting  to 
'other  APs,  and  a  server  accepting  connections  from  other  APs.  When  a  half  dozen  APs 
shared  a  compartment,  each  AP  would  be  a  client  to  each  of  the  5  remaining  APs,  and  act 
as  a  server  to  them  as  well.  Client/server  model  communication  is  doable  but  complex. 

Point-to-point  communication  is  useful  when  a  system  communicates  with  only  one,  or  at 
most  a  few  systems.  The  RSVP  communication  requirement  could  be  addressed  with  the 
point-to-point  model  by  connecting  N  Access  Points  with  N!  point-to-point  paths.  A  half 
dozen  APs  in  a  compartment  would  require  720  communication  paths.  Again  possible  but 
complex. 

The  publish/subscribe  paradigm  is  a  higher- level  communication  paradigm.  A  publisher 
makes  “topics”  of  information  available  to  subscribers.  For  example,  one  publisher  may 
broadcast  topic  “Temperature,”  and  another  publisher  may  broadcast  topic  “Humidity,” 
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and  yet  a  third  may  publish  “WindDirection.”  One  subscriber  may  request  topics 
“Temperature”  and  “WindDirection,”  while  another  subscriber  may  request  topics 
“Temperature”  and  “Humidity.”  The  publish/subscribe  software  has  responsibility  for 
insuring  that  topics  of  interest  are  communicated  between  publishers  and  subscribers. 

All  of  the  APs  in  a  compartment  need  data  from  all  sensor  clusters.  RSVP  shares  Sensor 
Cluster  data  among  all  of  the  APs  in  a  compartment  using  publish/subscribe.  Each  AP 
publishes  the  data  it  receives  from  its  radio  receiver  and  subscribes  to  all  of  its  peer’s 
data.  The  publication  topic  for  environmental  sensor  data  is  “COMPO  12/ENVDATA.” 
The  topic  is  like  a  file  path,  separated  into  components  with  slashes.  Subscribing  to  the 
topic  “COMP012/ENVDATA”  is  a  request  for  all  environmental  data  from  compartment 
12.  An  AP  both  publishes  Sensor  Cluster  data,  and  subscribes  to  Sensor  Cluster  data. 

In  addition,  to  simplifying  data  sharing,  the  publish/subscribe  paradigm  is  also  useful  in 
determining  the  AP  failure.  Every  AP  publishes  a  periodic  heartbeat  with  the  topic, 
“COMPO  12/AP0xx/HEARBEAT.”  Every  AP  also  subscribes  to  its  peer’s  heartbeat  with 
the  subscription  “COMPO  12/*/HEARBEAT,”  where  embedded  asterisk  is  the  wildcard 
character  that  means  “any.”  Thus,  the  subscriptions  will  include  the  publications 
“COMPO 1 2/APO 1 2/HE ARBEAT,”  “COMPO 1 2/AP04 5/HE ARBE AT,”  etc.  Since  each 
subscription  includes  an  optional  timeout  value,  the  failure  of  an  AP  to  publish  its 
heartbeat  will  trigger  a  subscription  timeout,  notifying  its  peers  that  it  is  inoperable.  The 
peer  cans  then  take  the  appropriate  evasive  action.  If  the  unavailable  peer  is  the  Primary 
AP  with  responsibility  for  communicating  with  the  Watch  Station,  the  Primary  AP’s 
Watch  Station  Communication  responsibilities  are  taken  over  by  another  AP. 

The  RSVP  system  has  about  25  different  kinds  of  publications.  The  publications  simplify 
data  sharing  and  provide  for  notification  on  system  failure.  The  publish/subscribe 
software  used  was  NDDS  purchased  from  Real-Time  Innovations,  155 A  Moffett  Park 
Drive,  Sunnyvale,  CA  94089.  The  product  was  reliable  and  well  supported.  The  API  was 
well  thought  out  and  the  learning  curve  was  short.  Resource  usage  was  minimal.  NDDS 
was  one  of  the  major  reasons  the  software  was  developed  on  time  and  on  budget. 

4.4.2.2  Programming  Language  and  Development 

The  RSVP  software  was  developed  using  Microsoft  Visual  C++  6.0  .  The  RSVP  AP 
application  was  written  in  ANSI  Standard  C++,  and  is  a  “command  line”  application.  It 
uses  neither  Windows,  the  Microsoft  Foundation  Class  nor  the  application  framework 
(afx).  The  Dinkumware  (398  Main  Street,  Concord,  MA  01742)  Standard  Template 
Library  was  used  extensively. 

The  RSVP  AP  application  is  heavily  multithreaded.  Event,  critical  section,  timer,  and 
mutex  synchronization  were  used  extensivly.  The  delivery  of  publication  information  was 
asynchronous.  On  the  arrival  of  publication  information  the  application  would  place  the 
information  into  a  queue,  an  event  would  be  signaled,  and  the  delivery  thread  would 
return.  The  signal  would  unblock  a  waiting  application  thread  that  would  read  the  queue 
and  process  the  publication  information. 
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C++  was  used  primary  for  encapsulation  within  classes.  Inheritance  played  an  important 
though  secondary  roll.  The  application  contains  73  classes.  Messages  were  passed 
between  the  classes  via  the  Publish/Subscribe  software,  via  synchronization  primitives 
and  intermediate  queues,  and  via  traditional  method  calls. 

4.4.2.3  Audio,  Video  and  Video  Compression 

Every  AP  is  equipped  with  a  microphone  and  a  video  camera  with  pan-tilt- zoom.  The 
cameras  composite  video  and  the  audio  feed  to  a  Videm  AV  (PCI)  video  capture  board 
manufactured  by  Winnov,  1043  Kiel  Court,  Sunnyvale,  CA  94089.  The  video  application 
at  the  AP  captures  the  video  at  5  frames  per  second.  The  video  is  compressed  with  a 
PICVideo  Motion  JPEG  codec  from  Pegasus  Imaging  Corporation,  4522  Spruce  Street, 
Suite  200,  Tampa,  Florida  33607.  The  audio  and  video  are  saved  as  avi  files  and  are 
displayable  with  widely  available  media  player  software.  Files  including  the  most  recent 
24  hours  of  video  are  retained  at  the  AP  for  retrospective  examination. 

After  compression,  a  320x240  video  frame  is  about  10k  in  size.  The  slow  frame  rate,  the 
small  image  size,  and  the  efficient  compression  allow  a  real  time  video  stream  to  be  sent 
over  the  network  to  the  Watch  Station  without  unduly  burdening  the  network.  The 
publish/subscribe  software  is  used  to  transfer  the  video.  The  video  publisher  application 
at  the  AP,  and  the  video  subscriber  application  at  the  Watch  Station  use  Microsoft’s 
Video  for  Window  API,  and  are  Windows  applications. 

On  request  from  the  Watch  Station,  a  video  stream  is  sent  from  the  AP.  The  camera’s 
pan-tilt- zoom  is  driven  from  the  Watch  Station  video  user  interface.  As  the  video  is 
presented  at  the  watch  station,  it  is  also  retained  as  avi  files.  Thus  the  video  system 
supports  two  types  of  retrospective  analysis.  Video  shown  at  the  watch  station  can  be 
replayed.  At  every  AP,  the  most  recent  24  hours  of  video  is  available. 

4.4.2.4  Communication  Between  the  Primary  AP  and  the  Watch  Station 

One  is  the  APs  in  a  compartment  is  given  the  responsibility  of  communicating  with  the 
Watch  Station.  This  “Primary”  AP  is  the  first  AP  to  be  started  in  a  compartment.  When 
the  first  primary  goes  off-line,  the  AP  with  the  highest  serial  number  in  a  compartment 
takes  its  place  as  the  Primary.  Communications  to  the  Watch  station  from  the  primary  AP 
include  environmental  alarms  and  sensor  data  readings.  Environmental  alarms  are 
triggered  by  high  temperatures  and  water  levels,  as  well  as  by  the  fulfillment  of 
environmental  criteria  that  indicate  fire.  In  addition,  the  watch  station  may  request 
continuously  updated  sensor  readings.  In  this  case,  when  the  Primary  AP  receives  data 
from  a  sensor  of  interest,  it  is  forwarded  to  the  Watch  Station. 
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4.4.2.5  Alarm  Generation 

Multiples  times  a  minute,  every  AP  examines  compartment  data  searching  for  evidence 
of  alarm  conditions.  RSVP  alarm  conditions  include  fire,  flood,  high  temperature  and 
abnormal  structural  strain.  Every  AP  does  a  complete  alarm  analysis,  but  only  the 
Primary  AP  presents  the  alarm  information  to  the  Watch  Station.  Flood,  high  temperature 
and  abnormal  structural  strain  alarms  are  determined  by  testing  sensor  values  against 
preset  values.  When  the  values  are  exceeded  in  multiple  sensor  clusters,  an  alarm  is 
generated.  Fire  detection  is  more  complex. 

Fire  detection  uses  multiple  variable  discrimination.  Sensor  data  was  gathered  from  a 
series  of  test  fires  and  used  to  build  fire  models.  The  test  fires  burned  a  variety  of  fuels 
including  hydrocarbons  heptane  and  #2  fuel  oil,  wood  and  wood  derivatives  including 
excelsior  and  paper,  plastics  characteristic  of  printed  circuit  boards,  and  edible 
polysaccharides  like  pop  tarts  and  toast.  Sensor  data  was  also  gathered  on  the  ignition 
products  of  welding. 

For  each  of  these  fires,  a  set  of  discrimination  coefficients  was  generated  that  modeled 
the  fire.  The  sum  of  the  products  of  the  discrimination  coefficient  and  the  transformed 
sensor  reading  determined  the  probability  of  fire.  Every  set  of  sensor  readings  was 
analyzed  using  all  of  the  fire  models.  When  multiple  fire  models  produced  a  high 
probability  of  fire  from  the  data  on  multiple  sensors,  the  fire  alarm  was  sent  to  the  Watch 
station.  Raw  sensor  readings  were  transformed  to  eliminate  both  the  effects  of  sensor 
aging  with  a  long  term  filter,  and  the  effects  of  transients  with  a  short  term  filter. 

The  major  contributors  to  the  success  of  the  software  effort  were:  the  acquisition  of  the 
NDDS  publish/subscribe  software,  the  use  of  object  technology,  and  the  use  of  the 
Standard  Template  Library  containers.  The  publish/subscribe  software  allowed  the 
developers  to  bypass  the  complexity  of  network  communications.  Object  technology 
provided  the  framework  for  developing  a  system  of  independent  entities  communicating 
via  messages.  The  Standard  Template  Library’s  container  classes  were  used  as  data 
repositories. 

4.4.2.6  RF  Architecture 

The  low  power  radio  frequency  (RF)  network  is  described  in  detailed  in  the  RSVP  formal 
report  called  “The  Radio  Network  Communication  Specification”  [ref  13].  The  technical 
report  describes  the  hardware  and  protocols  used  to  implement  the  custom,  low-power 
wireless  portion  of  the  Reduced  Ships-Crew  by  Virtual  Presence  (RSVP)  system. 

The  areas  to  which  this  document  is  applicable  are  the  environmental,  structural  and 
personnel  monitoring  functions.  Coverage  includes  all  functionality  of  the  Access  Point 
Communications  Module  (APCM),  aspects  of  the  sensor  clusters  that  pertain  to  system 
communication,  and  all  functionality  of  the  personnel  status  monitor  from  the  antenna  to 
the  processor-processor  interface.  The  messages  being  sent  throughout  the  RSVP  system 
are  covered  by  “Integrated  Communications  Specification  Report”  [ref  14], 
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4.5  Watchstation 
4.5.1  Overview 

The  purpose  of  the  RSVP  Watchstation  (WS)  is  to  provide  a  means  of  demonstrating 
compartment  level  virtual  presence  based  on  the  technologies  and  system  developed 
during  the  RSVP  ATD.  The  WS  is  a  prototype  example  for  demonstrating  the  underlying 
technologies;  advanced  distributed  sensing  capabilities  (MEMS,  power  scavenging, 
distributed  processing),  wireless  networking  communication  and  a  robust  data  to 
information  fusion  architecture  in  an  integrated  system.  As  such,  the  RSVP  Watchstation 
is  not  intended  to  be  a  finished  product  for  implementation.  The  Watchstation  does 
provide  an  example  of  things  to  consider,  including  form  and  function,  when  developing 
and  implementing  the  under  lying  technologies  in  the  future.  A  properly  designed  human- 
centered  interface  will  be  essential  in  realizing  the  full  benefits  of  reduce  manning 
through  technologies  leading  virtual  presence. 

The  WS  provides  a  means  for  interactive  viewing  of  selected  system  data  as  well  as 
asynchronous  updates  due  to  alarm  conditions.  The  viewing  of  system  data  will  be  by 
hierarchical  interaction  with  graphical  screen  objects.  To  facilitate  rapid  prototyping  for 
the  RSVP  demonstration  effort,  a  COTS  software  package,  Sammi  (Standard  Application 
Man  Machine  Interface)  and  NDDS  (Network  Data  Delivery  System),  have  been  selected 
to  provide  graphical  user  interface  and  data  communication  development  environments. 

Watchstation  hardware  consists  of  an  industrial  rack  mount  PC,  two  20  inch  touch 
screens,  keyboard,  mouse  and  associated  interconnect  cabling.  Watchstation  software 
consists  of  Windows  NT  operating  system,  NDDS  communication  software  and  a 
commercial  graphical  user  interface  software  package. 

Specific  details  of  the  hardware,  software  interface  design  and  User  Interface 
development  are  described  in  the  following  sections. 
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4.5.2.2  Watchstation  Installation  -  CG61  USS  MONTEREY 


The  Watchstation  hardware  was  located  in  the  Central  Control  Station  (CCS)  aboard  the 
USS  Monterrey.  The  Watchstation  CPU  was  rack  mounted  in  the  ICAS  cabinet  in  a  spare 
slot.  The  two  touch  sensitive  screens,  keyboard  and  mouse  were  located  near  the  aft 
bulkhead  in  CCS  on  small  work  table  designed,  fabricated  and  installed  to  support  the 
RSVP  At  Sea  Demonstrations.  The  Watchstation  hardware  is  shown  in  Figure  73  and 


Figure  74 


Figure  73  Watchstation  Screens 


Figure  74  Watchstation  CPU  Mounted  in  ICAS  Rack 
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4.5.3  Software 

4.5.3.1  Overview 

All  communication  between  the  watchstation  user  interface  (WSUI)  and  subsystems  is 
accomplished  by  either  direct  communication  with  APs  or  data  flow  routed  through  APs. 
Figure  75  presents  an  overview  of  the  system  hierarchy.  The  WSUI  is  designed  to 
provide  for  interactive  viewing  of  selected  system  data  as  well  as  asynchronous  updates 
due  to  alarm  conditions.  The  viewing  of  system  data  is  by  hierarchical  interaction  with 
graphical  screen  objects.  To  facilitate  rapid  prototyping  for  the  R8VP  demonstration 
effort,  two  COTS  software  packages,  Sammi  (Standard  Application  Man  Machine 
Interface)  and  NDDS  (Network  Data  Delivery  System),  were  selected  to  provide 
graphical  user  interface  and  data  communication  development  environments. 

A  commercially  available  graphical  interface  and  communication  development  package 
manufactured  by  Kinesix  was  chosen  to  implement  the  WSUI  objects  necessary  to 
present  preprocessed  information  from  the  subsystems.  Standards-based  Advanced  Man 
Machine  Interface  (SammiR)  is  a  client/server  and  Web-based  software  development 
toolkit  for  creating  graphical,  networked  or  embedded  applications  that  are  data,  event, 
and  command  driven.  It  consists  of  a  graphical  editor  for  creating  user  interfaces; 
multiple  executable  programs  that  manage  the  user  interfaces  and  network 
communieatbions  during  runtime;  libraries  and  tools  for  developing  distributed 
applications  that  communicate  with  the  Sammi  runtime  programs  and  interact  with  end- 
users;  and  libraries  and  tools  for  customizing  and  enhancing  the  graphical  editor  and 
runtime  programs.  It  Is  designed  to  facilitate  control  and  monitoring  in  distributed 
networks  and  is  suitable  for  the  RSVP  application. .  Kinesix  Corporation  located  in 
Houston,  TX  markets  SammiR. 

NDDS  network  middleware  software  manufactured  by  Real-Time  Innovations  (RTI)  was 
selected  to  meet  the  requirements  for  real-time  data  exchange  between  APs  and  to  allow 
both  publish/subscribe  and  client/server  request/reply  paradigms. 

The  WSUI  to  AP  interface  design  requires  a  definition  of  the  interface  between  the 
Sammi  and  NDDS  software  as  well  as  the  structure  of  the  interface  between  NDDS  and 
the  data  for  each  subsystem. 
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Figure  75  RSVP  System  Architecture 


4.5.3.2  Sammi 

The  Sammi  environment  provides  the  capability  to  build  graphical  user  interface  (GUI) 
formats  (screens)  by  using  Dynamic  Data  Objects  (DDOs).  The  interface  screens  are 
constructed  by  dragging  and  dropping  an  available  set  of  DDOs.  The  DDOs  contain 
extensions  to  allow  data  and  commands  to  be  sent  to  and  from  the  GUI  formats  to 
distributed  peer  server  processes.  The  Sammi  Runtime  Environment  (RTE)  manages  the 
interactions  between  the  DDOs  and  the  server  processes.  DDOs  for  both  data  input  and 
output  are  provided  in  the  form  of  integers,  floats,  strings,  charts,  buttons,  sliders,  alarms, 
etc. 

DDOs  allow  a  server  process  to  be  specified  such  that  bi-directional  data  communication 
can  occur  between  a  DDO  element  and  a  server  located  anywhere  in  the  network.  The 
communications  are  based  upon  underlying  remote  procedure  calls  (RPCs).  Input  DDOs 
allow  one  or  more  commands  to  be  sent  to  either  a  specified  server  or  the  Sammi  RTE. 
Commands  sent  to  the  RTE  provide  facilities  to  add  and  delete  window  formats  and  make 
layers  within  a  format  visible/invisible,  among  other  features.  Commands  sent  to  user 
peer  server  processes  are  event  driven,  and  several  events  can  be  initiated  sequentially 
based  upon  DDO  inputs  such  as  button  clicks.  In  addition,  a  peer  server  process  can  send 
commands  to  the  RTE  such  that  the  peer  server  can  affect  change  in  the  current  state  of 
the  GUI. 

There  are  two  underlying  methods  to  communicate  information  between  a  DDO  and  a 
server:  polled  and  asynchronous.  For  each  DDO,  the  protocol  is  specified  as  either  polled 
or  peer  (the  asynchronous  method  is  provided  by  the  peer  protocol)  along  with  the  server 
name.  For  polled  data,  the  server  only  sends  DDO  updates  when  requested  to  do  so  by  the 
RTE,  based  on  a  rate  specified  by  the  DDO.  The  peer  data  protocol  provides  for 
asynchronous  updates  where  the  server  process  drives  the  update  rate.  The  peer  protocol 
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is  envisioned  as  the  primary  protocol  to  support  the  WSUI  since  much  of  the  RSVP 
system  data  will  arrive  asynchronously.  Figure  76  illustrates  the  Sammi  structure. 


User  Interface 


Sammi  Runtime  Environment  Server  Application 


Figure  76  Sammi  Structure 


4.5.33  NDDS 

The  NDDS  environment  provides  a  middleware  component  for  communications  between 
APs  and  the  WSUI.  It  provides  a  standard  client/server  architecture  as  well  as  a 
publish/subscribe  paradigm. 

Client  and  server  message  object  classes  can  be  created  anywhere  in  the  network.  These 
disjoint  objects  communicate  by  client  objects  initiating  requests  to  NDDS  server  objects. 
The  client  can  wait  for  the  server  to  respond  to  the  request  or  install  a  callback  to  provide 
notification.  This  structure  is  often  referred  to  as  a  request/reply. 

The  NDDS  publish/subscribe  architecture  allows  publications  to  be  registered  over  the 
network.  Then  the  subscription  object  “subscribes  to  a  message”  which  results  in  the 
publication  object  sending  its  message  data  to  the  subscribing  object.  Using  this 
paradigm,  no  data  is  actually  sent  by  a  publishing  object  until  requested  by  a 
corresponding  subscription  object.  The  publish/subscribe  protocol  allows  data  to  be  sent 
to  a  client  process  without  the  need  for  the  client  to  issue  requests  (polling)  each  time 
data  becomes  available, 

4.53.4  Sammi/NDDS  Interface  (SNI) 

The  Sammi  peer  server  code  enabled  the  mapping  of  data  between  Sammi  DDO  objects 
and  the  NDDS  message  environment  and  is  termed  the  Sammi/NDDS  interface  (SNI). 
The  NDDS  data  is  encapsulated  in  message  classes,  which  provide  data  input  and  output 
via  both  publish/subscribe  and  request/reply  protocols. 
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For  each  NDDS  message,  a  data  member  called  a  topic  is  used  to  instantiate  the  object 
and  to  identify  the  particular  data  structure  contained  within  the  message.  In  addition, 
separate  identifiers  are  used  to  identify  the  particular  instance  of  the  message  and  the 
location  of  the  data  in  the  network.  An  NDDS  message  can  then  be  instantiated  for 
several  different  topics,  each  containing  different  data  structures  corresponding  to 
particular  data  sources.  The  peer  server  is  also  designed  to  facilitate  the  integration  of 
database  message  classes  to  allow  the  integration  of  a  local  database  into  the  watchstation 
software.  Figure  77  illustrates  the  general  interaction  between  DDOs,  the  Sammi  RTE, 
the  peer  server,  NDDS  messages  and  database  messages. 


User  Interface 

DDO 

Input  Data 
DDO 

Output  Date 


DDO 

Input  Commands  ^ 


DDO 

Output  Commands 

-4 


Messages 

Data  Request^ 


Data  Replies 


Publication 

Requests 


Published  Data 

4 - 


NDDS 


Database 

Query 


Figure  77  Generalized  Sammi/NDDS/Database  Message  Interaction 


Event  services  handled  by  the  SNI  peer  server  serve  as  the  basis  for  coordinating  the 
exchange  of  data  between  the  WSUI  and  the  APs.  The  event  services  process  are  notified 
in  response  to  Sammi  exposure,  de-exposure  and  command  events.  These  events  are  used 
to  initiate  dynamic  subscriptions  and  publications,  client/server  requests  or  database 
requests.  The  generalized  data  flow  is  illustrated  in  Figure  78  Interface  Data  Flow. 
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4.5.4  User  Interface  Design 

Development  of  the  RSVP  User  Interface  consisted  of  a  series  of  tasks  that  included; 
requirements  definition,  concept  development,  design  specification,  screen  development 
and  User  Interface  documentation.  Each  of  these  tasks  is  described  fully  in  the  following 
reports.  A  brief  synopsis  of  each  is  included  in  the  sections  that  follow. 

•  Definition  of  Data/Information  Requirements  to  Support  Virtual  Presence 

•  Illustrative  HC1  Concept  for  Virtual  Presence 

•  User  Interface  Design  Specification 

•  User  Interface  Specification  and  Functional  Operation  Description  Document 

•  User  Interface  Storyboard  Graphics 

•  RSVP  Watchstation  Interface  User  Guide 

The  final  User  Interface  layout  consisted  of  two  screens  to  support  navigation  and  access 
to  information/data  requirements  identified  for  the  RSVP  demonstrations.  The  multi¬ 
screen  configuration  was  selected  based  the  Multi-Modal  Watch  Station  development 
efforts  and  the  Integrated  Command  Environment  (ICE)  demonstration  facility  located  at 
NSWC  Dahlgren  Division  located  in  Dahlgren,  VA.  Once  the  requirements,  design  and 
basic  layout  were  finalized,  Navigation  and  Data  screens  were  created  for  each  of  the 
four  functional  monitoring  areas. 

4.5.4.1  Approach 

Based  on  the  functional  requirements  identified  in  the  systems  engineering  study  to 
support  situational  awareness  requirements  for  reduced  crew  ship  operation 
a  virtual  presence  concept  and  an  implementation  approach  was  developed. 

In  the  developing  the  initial  concept  much  of  the  effort  focused  on  defining  user  interface 
requirements  in  terms  of  Took  and  feel’  and  functional  capabilities.  This  process 
involved;  developing  a  set  of  common  user  interface  requirements  for  use  within  RSVP, 
developing  notional  screens  for  discussion,  describing  an  approach  for  integrating 
technology  into  systems  and  assessing  user  interface/  presentation  techniques  and 
technologies.  These  efforts  were  based  on  industry  experience/  applications  to  develop 
efficient  user  interfaces  to  manage  complex  systems  with  fewer  and  fewer  people. 
Additionally  a  definition  for  virtual  presence  was  established  to  help  provide  context  for 
requirements  and  system  development. 

4.5.4.2  Virtual  Presence/  Situational  Awareness 

Dr.  Dick  Pew  at  BBN  Technologies  provided  the  following  definition  and  information  on 
Virtual  Presence  and  Situational  Awareness.  Dr.  Pew  is  an  expert  in  human- factors 
engineering  and  human- centered  design.  Dr.  Pew  has  authored  a  chapter  “The  State  of 
Situation  Awareness  Measurement:  Circa  1996,”  to  appear  in:  Experimental  Analysis  and 
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Measurement  of  Situation  Awareness,  D.  Garland  &  M.  Endsley,  Published  by  Lawrence 
Erlbaum  Associates,  Inc.,  Mahwah,  NJ. 

A  very  standard  definition  of  Situational  Awareness  (SA)  is:  "The  perception  of  the 
elements  in  the  environment  within  a  volume  of  time  and  space,  the  comprehension  of 
their  meaning  and  projection  of  their  status  in  the  near  future." 

SA  is  a  property  of  the  operator,  supported  by  the  information  sources  available,  not  a 
property  of  the  machine,  system  or  the  displays  themselves.  The  human  interface 
supports  the  development  of  SA  but  is  not  a  part  of  it. 

In  Dr.  Pew’s  book  chapter,  he  breaks  it  into  two  parts,  defining  a  "situation"  and  defining 
"awareness" 

His  definition  of  a  situation  is:  "a  set  of  environmental  conditions  and  system  states  with 
which  the  participant  is  interacting  that  can  be  characterized  uniquely  by  a  set  of 
information,  knowledge  and  response  options." 

He  goes  on  to  distinguish  information  from  knowledge.  Information  being  the  raw  data 
that  is  coming  in  from  the  environment  and  is  changing  frequently.  Knowledge  being  the 
stuff  that  is  in  the  head  of  the  operator,  which  he  or  she  uses  to  interpret  the  information 
that  is  being  received.  This  knowledge  is  based  on  training  and  experience. 

Dr.  Pew  cautions  not  to  define  SA  to  be  the  sum  total  of  everything  one  might  possibly 
need  to  know,  because  SA  is  situation  specific.  When  we  ask  whether  an  operator  had 
adequate  SA,  we  need  to  know  what  was  needed  at  the  time  in  question.  This  is  important 
because  the  information  required  is  constantly  changing  and  it  is  impossible  to  know 
everything  all  the  time. 

Based  on  the  definitions  above,  the  elements  of  Awareness,  ‘Given  the  Situation’  are: 

•  Current  state  of  the  system  (including  all  the  relevant  variables). 

•  Predicted  state  in  the  "near"  future. 

•  Information  and  knowledge  required  in  support  of  the  crew's  current  activities. 

•  Activity  Phase 

•  Prioritized  list  of  current  goal(s) 

•  Currently  active  goal,  subgoal,  task 

•  Time 

•  Information  and  knowledge  needed  to  support  anticipated  "near"  future  contexts. 

The  information  sources  can  be  of  great  variety,  including: 

•  Sensory  information  from  the  environment 

•  Visual  and  auditory  displays 

•  Decision  aids  and  decision  support  systems 

•  Extra-  and  intra-crew  communication 

•  Crew  member  background  knowledge  and  experience 


183 


NSWCCD-TR-2003/02 


The  following  bullets  summarize  the  definition  of  Virtual  Presence  in  Support  of 
Achieving  Situational  Awareness.  This  definition  is  applicable  to  any  aspect  of  ship. 

•  Information  and  Knowledge  Needed  to  Manage  All  Aspects  of  a  Space,  Machine, 
Environment  or  Situation  in  All  Possible  Scenarios  (Multiple  Contexts) 

•  Accomplished  by  Fusing  Data  from  Multiple  Sources  to  Determine  The  Operational 
State  and  Condition  -  Both  Static  and  Dynamic 

•  Information/Knowledge  that  is  Derived  from  the  Raw  Data  Is  Conveyed  to  the 
Operator  in  a  Coherent,  Navigable,  Efficient  Manner 

•  Supports  the  Management  of  Complex  Systems  with  a  Minimum  Number  of  People 

4.5.4.3  UI  Functional  Requirements 

User  Interface  Requirements  documented  in  the  Definition  of  Data/Information 
Requirements  to  Support  Virtual  Presence  Report  were  designed  to  foster  ease  of  use  as 
well  as  user  acceptance  and  trust  in  the  RSVP  system. 

Requirements  were  divided  into  eighteen  categories  as  follows; 

•  Form  and  function  -  12 

o  Consistency 
o  Navigation 
o  Visual  Appeal 
o  Terminology 
o  Organization 
o  Response  Time 
o  Reliability 
o  Feedback 
o  Error  Prevention 
o  Alert/Alarms 
o  User  Configuration 

•  Hardware  -  2 

o  Input  Devices 
o  Output  Devices 

•  Monitoring  Types 

o  General 
o  Machinery 
Environmental 
o  Structural 
o  Personnel 
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Ease  of  use  had  to  be  supported  through  consistent  application  of  standards  familiar  to  the 
users  (e.g,,  the  user  interface  guidelines  for  the  Microsoft  Windows  graphical 
environment).  Ease  of  use  needed  to  be  further  supported  by  the  presentation  of  a  visually 
appealing  user  interface  that  provides  a  sense  of  control.  Consistent  user  interface 
designs  that  incorporated  direct  manipulation  metaphors,  availability  of  context-specific 
help,  streamlined  navigation  strategies,  local  language  presentation,  and  minimal  use  of 
modes  would  help  to  induce  a  sense  of  user  control.  Consistency  both  with  respect  to 
users5  task  models  and  with  respect  to  all  functional  areas  within  RSVP  was  desirable. 

The  UI  design  needed  to  maximize  the  interactive  nature  of  the  user  interface  to  provide 
users  with  direct  and  intuitive  means  to  accomplish  their  tasks.  The  user  had  to  be  able 
to  navigate  among  functional  areas  and  within  functional  areas  in  a  direct  manner.  The 
interface  also  had  to  be  visually  appealing  with  easily  interpretable  visual  elements  and 
minimal  visual  clutter. 

Information  had  to  be  presented  in  a  form  immediately  usable  by  the  user  and  arranged  in 
a  manner  consistent  with  user  expectations.  Data/input  to  the  user  interface  by  the  user 
would  need  to  be  validated  in  a  timely  manner  and  feedback  provided  in  a  direct,  prompt, 
and  appropriate  manner.  Positive,  prompt,  and  direct  feedback  would  be  required  to 
enhance  the  user’s  sense  of  control.  Additionally,  error  avoidance  techniques  would  be 
needed  to  reduce  user  errors  and  frustration  and  increase  user  productivity  were  included. 

4.5A.4  UI  Development 

The  introduction  of  advanced  technology  into  a  workplace  does  not  in  and  of  itself 
guarantee  more  efficient,  safer,  or  easier  to  use  systems.  In  many  cases,  the  inclusion  of 
advanced  technology  has  increased  system  complexity  without  sufficiently  reducing  the 
potential  for  human  error  or  mitigating  the  consequences  of  such  error.  Technology  only 
provides  an  opportunity  to  enhance  system  effectiveness  through  its  provisions  of 
flexibility,  increased  functionality,  and  greater  access  to  information 

The  features  that  are  deemed  benefits  of  technology  are  the  same  features  that  create 
potential  hazards  for  users.  Thus,  it  is  not  the  presence  of  technology  but,  how  that 
technology  is  integrated  into  a  system  and  used  by  the  operators  that  will  determine  its 
effectiveness.  Successful  integration  and  use  depends  on  knowledge  of  operators  and 
their  work  environment,  habits,  tools,  and  tasks  in  addition  to  the  design  of  a  usable  and 
friendly  system  interface. 

4. 5.4. 4.1  Successful  Technology  Integration 

The  key  to  successful  technology  integration  into  complex  systems  is  the  use  of  a  user- 
centered  design  process.  Many  design  teams  are  familiar  with  human  factors  design 
principles.  But  few  are  aware  of  the  importance  of  user-centered  design  processes,  or 
even  the  distinction  among  the  two.  Where  human  factors  design  addresses  user  interface 
issues,  user-centered  approaches  address  underlying  system  issues.  User  interfaces  that 
conform  to  human  factors  principles  will  have  appropriate  interaction  mechanisms,  page 
layout,  labels,  color  coding,  alarm  presentation,  etc.  User  interfaces  that  evolved  from 
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user-centered  processes  will  have  all  of  the  preceding  benefits  as  well  as  functional 
decompositions,  navigation  schemes,  data  visualization  techniques,  and  information 
content  that  supports  operator  efficiency,  accurate  diagnosis,  and  appropriate  decision 
making. 

4. 5. 4. 4. 2  User-Centered  Design  Process 

User- centered  design  is  an  iterative  design  process  that  has  implications  not  only  for  user 
interface  design,  but  also  for  system  design.  The  process  is  intended  to  be  used  early  in 
system  development  and  continuously  throughout  the  system  development  lifecycle.  A 
user-centered  design  process  guides  the  selection  and  development  of  system 
functionality.  Functionality  decisions  based  on  this  process  help  ensure  the  system 
provides  features  users  need  and  thus  will  be  more  likely  to  accept  and  use. 

As  outlined  below,  the  process  encompasses  many  design  and  evaluation  tools  including 
the  application  of  human  factors  principles  to  the  development  of  user  interfaces.  A 
majority  of  the  data  collected  in  early  steps  of  the  process,  comes  directly  from  users. 
Their  involvement  early  in  the  process  fosters  their  acceptance  of  the  final  system  in 
addition  to  increasing  the  likelihood  that  technology  will  successfully  be  integrated  into 
the  system. 

Development  of  the  RSVP  User  Interface  followed  a  user-centered  design  process 
consisting  of  four  steps;  1)  Understand  the  users,  2)  Develop  design  style  guide,  3) 
Implement  solution  in  accordance  with  style  guide,  4)  Establish  continuous  improvement 
process.  This  process  was  developed  at  Honeywell  Technology  Center  Inc.  and  has  been 
used  successfully  on  a  large  scale  to  address  issues  affecting  successful  technology 
integration.  The  four  steps  are  fully  documented  in  the  Definition  of  Data/Information 
Requirements  to  Support  Virtual  Presence  Report 

The  RSVP  team  followed  the  four- step  process,  first  by  meeting  with  end  users  and 
conducting  interview  at  the  Aegis  Readiness  Training  Center  Detachment  (ARTCD) 
located  at  the  LBES  at  NSWCCD  in  Philadelphia.  A  total  of  9  interviews  were  conducted 
with  a  wide  range  of  ratings  and  ship  experience  as  well  as  LBES  trainers  and  engineers. 
Interview  were  also  conducted  with  and  questionnaires  distributed  to  personnel 
knowledgeable  in  the  area  of  structures  to  gain  a  ship  level  perspective  of  structural 
monitoring  requirements  as  well  damage  control  experts  with  respect  to  all  four 
functional  areas;  machinery,  environment,  structure  and  personnel.  An  Illustrative  HCI 
Concept  for  Virtual  Presence  was  then  developed,  providing  the  basis  for  development  of 
the  User  Interface  Design  Specification,  User  Interface  Specification  and  Functional 
Operation  Description  Document  and  User  Interface  Storyboard  Graphics.  As  the 
development  of  the  RSVP  system  evolved,  these  documents  were  revised  to  reflect  the 
RSVP  implementation.  Operation  of  the  interface  demonstrated  aboard  CG61  USS 
MONTEREY  is  documented  in  the  RSVP  Watchstation  Interface  User  Guide. 
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4.5.4,5  UI  Design  Specification 

The  User  Interface  Design  Specification  serves  as  the  information  content  specification 
for  the  RSVP  user  interface  -  it  describes  the  information  contained  in  the  interface.  It 
describes  the  information  presented  on  each  screen  along  with  a  description  of 
presentation  format.  The  User  Interface  Storyboard  Graphics  document  and  the  User 
Interface  Specification  and  Functional  Operation  Description  document  describe  the  form 
(look)  and  functionality  of  the  UI.  The  storyboard  document  illustrates  interaction 
mechanisms,  screen  layout,  formatting,  and  organization  while  the  specification  and 
operation  document  describes  the  interaction  mechanisms  employed  in  the  interface  and 
system  behavior.  The  following  figures  were  taken  from  the  storyboard  document. 

The  user  interface  described  herein  is  based  on  a  user  workstation  that  contains  two 
medium  format  (at  least  1024x768)  displays,  a  keyboard,  and  a  cursor  control  device 
(e.g.,  a  mouse).  This  document  is  divided  into  eight  major  sections  -  crew,  environment, 
structure,  machines,  documentation,  system,  events,  and  navigation.  The  first  seven 
sections  comprise  the  content  of  the  right-hand  display  screen  (i.e.  the  task  screen  the 
navigation  screen)  and  the  eighth  section  a  description  of  the  left-hand  display  screen 
(i.e.,  the  navigation  screen)  (Figure  79).  The  information  requirements  are  described 
under  each  section. 
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Figure  79  User  Interface  Framework 


Content:  description  of  required  information  including  references  or  justification  as  necessary 

Format:  presentation  format  of  information-  text,  icon,  graphic,  animation,  button,  etc.  _ 

Region :  the  region  of  the  interface  where  the  information  will  be  displayed  -  condition  indicator,  hazard  indicator,  navigation,  data, 

alarm,  procedures,  status  bar,  etc. _ _ _ 

Page :  the  associated  page  number  in  the  accompanying  PowerPoint  document  of  screen  layouts. _ 


4. 5.4. 5.1  Navigation 

The  design  of  the  navigation  screen  is  intended  to  provide  both  an  at-a-glance  status 
overview  of  the  entire  ship  and  selected  compartments,  as  well  as  easy  navigation 
throughout  the  compartments  and  systems  of  the  ship.  The  steaming,  hatch,  and  hazard 
icons  maintain  an  overall  context  for  the  operator.  Pulldown  menus  from  hatch  and 
hazard  icons  provide  direct  links  to  the  relevant  areas  of  the  ship,  as  requested  in  expert 
interviews.  Also  based  on  interviews,  the  two  methods  of  navigation — ship  and  list — 
mirror  the  differences  in  how  damage  control  and  engineering  think  about  the  ship.  Icons 
in  the  compartment  represent  functional  areas,  providing  event/alarm  status  and  access  to 
appropriate  data  pages.  These  icons  are  layered  so  that  the  operator  controls  the  amount 
of  clutter  on  the  screen. 
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4.5. 4.5.2  Documents 

The  document  area  provides  a  common  area  for  procedures,  manual  pages,  maintenance 
logs,  and  event  histories.  This  kind  of  knowledge  is  often  requested  in  expert  interviews, 
and  according  to  knowledge  management  experts,  to  be  truly  effective,  it  needs  to  be  as 
integrated  as  possible  with  the  user’s  actual  task  environment. 

4.5.4.53  Events 

According  to  our  expert  interviews,  one  of  the  biggest  requests  for  alarms  was  that  they 
clearly  and  specifically  provide  symptoms,  diagnosis,  and  procedures  in  addition  to  basic 
notification.  The  operators  don’t  want  to  “have  to  search  for  the  fault.”  Our  design 
provides  this  capability  with  a  combination  of  an  event  list  and  event  summaries.  The 
event  list  is  always  visible.  From  each  event  ertry,  the  operator  can  open  a  more  detailed 
summary,  or  jump  straight  to  the  relevant  data  page,  or  source,  to  see  the  raw  data  related 
to  the  event.  Each  event  summary  provides  information  such  as  duration,  symptoms,  and 
prognosis,  as  well  as  direct  links  to  appropriate  maintenance  logs,  manuals,  and  event 
histories. 

Another  problem  is  information  overload;  therefore,  the  event  list  is  sorted,  and  events 
are  combined  where  possible.  In  interviews,  experts  were  excited  about  the 
status/acknowledgement  capabilities;  they  felt  it  could  easily  replace  the  currently 
tedious,  paper-based  event  logs. 

4.5.4.5.4  Crew 

The  crew  section  provides  an  at-a-glance  overview  of  the  crew  members  in  a  given 
compartment,  as  well  as  access  to  individual  crew  data.  The  design  is  intended  to  foster 
rapid  decisions  based  on  location,  function,  vitals,  and  mobility — Where  are  they?  Is 
there  something  wrong?  What  can  they  do?  For  example,  from  interviews,  damage 
control  experts  are  interested  in  determining  who’s  closest  to  a  casualty,  or  in 
determining  the  optimal  amount  of  time  a  firefighter  can  stay  in  a  compartment.  The 
compartment  organization  allows  for  such  decisions. 

Additional  points: 

•  Alarms  are  combined  so  that  only  the  “most  important”  alarm  for  each  crew 
member  is  displayed.  This  b  to  keep  an  operator  from  being  overwhelmed  with 
multiple  alerts,  usually  stemming  from  the  same  cause. 

•  According  to  interviews,  heart  rate  is  still  the  most  practical  measure  of  heat 
stress.  Thus  heart  rate  appears  first  in  the  health  details  group  for  each  crew 
member. 

•  Station  information  gives  expertise  and  work  assignments  for  each  crew  member. 
This  can  help  with  crew  management  decisions.  Who’s  the  closest  on-duty 
machinist  to  SSGTG  2?  LCDR  Miller  is  down,  should  a  substitute  medical  team 
member  be  placed  on-duty?  Etc.. 
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4.5.4.S.5  Environment 

The  environment  section  provides  a  status  overview  of  each  environmental  parameter 
measured  for  a  compartment,  and  direct  access  to  raw  sensor  readings  if  necessary. 
Because  a  compartment  can  be  large  and  contain  multiple  sensors,  maximum  and 
minimum  readings  are  displayed  in  the  overview  along  with  status  information. 
Habitability  was  habitually  mentioned  in  expert  interviews  as  another  crucial  aspect  of 
environment,  and  wet  bulb  temperature  was  requested  as  an  important  decision  aid. 


4. 5.4. 5.6  Machinery 

In  interviews,  experts  mentioned  that  one  thing  they  really  like  about  a  few  of  the  current 
monitoring  systems  is  the  ability  to  see  the  most  important  parameters  for  multiple  pieces 
of  machinery  at  once.  For  instance,  in  “lull-power”  situations  like  fueling,  engineers  like 
to  see  data  about  all  generators  on  one  screen.  The  machinery  overview  screen  provides 
this  capability.  Furthermore,  the  ranged  bars  allow  an  engineer  to  more  quickly  see  which 
are  parameters  are  high,  and  how  parameters  relate  to  each  other. 

The  next  level  offers  an  overview  of  the  sub -components  of  a  single  piece  of  machinery, 
including  alarm  status,  important  parameter  readings,  trending,  and  visualization  of  the 
machinery.  Because  there  is  some  difference  of  opinion  between  engineers  on  which 
parameters  are  generally  most  important,  operators  can  customize  which  parameters  are 
displayed  on  both  of  these  levels. 

Finally,  the  last  level  of  detail  provides  screens  of  every  parameter  monitored  for  a  sub¬ 
component.  However,  with  these  screens,  the  operator  should  rarely  have  to  search  for 
desired  parameters  amongst  all  the  data  at  this  level. 


4. 5. 4. 5. 7  Structure 

Unlike  the  other  functional  areas,  stress  and  shock  relate  more  to  the  entire  ship  than  to 
individual  compartments.  Therefore,  the  initial  structure  overview  screen  provides  ship¬ 
wide  readings,  including  a  stress  map  to  help  operators  visualize  stress  across  the  entire 
hull.  At  the  compartment- level,  an  overview  screen  similar  to  the  environment  overview 
shows  information  about  each  structure  parameter  measured  by  a  sensor  in  that 
compartment. 


4.S.4.5.8  System 

While  important  for  configuration  and  maintenance,  the  typical  watchstander  doesn’t  care 
about  the  internals  of  the  RSVP  system,  it  only  provides  additional  information  overload 
and  distracts  from  the  day-to-day  monitoring  of  the  ship.  In  fact,  the  experts  we 
interviewed  already  have  a  name  for  this  kind  of  system- level  data — trivia.  Therefore, 
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we’ve  made  this  a  separate  area  of  the  interface,  ideally  accessible  only  by  authorized 
support  engineers.  Therefore,  in  the  final  system  this  section  of  the  interface  would  not  be 
visible.  It  would  only  appear  if  the  user  logging  into  the  system  was  authorized  to  see  this 
information.  Once  in  this  section  of  the  interface,  operators  can  see  the  location  of  all 
RSVP  components  (access  points,  sensor  clusters,  SHMs,  ICHMs)  in  a  compartment, 
using  layers  to  help  reduce  clutter.  Operators  can  then  click  on  individual  components 
and  monitor  details  like  battery  levels,  or  modify  thresholds. 
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4.S.4.6  RSVP  User  Interface 

The  general  screen  interaction  is  accomplished  through  a  point  and  click  interface.  The 
system  uses  a  dual  touch  screen  setup;  the  left  monitor  is  used  as  the  selection  screen  and 
the  right  monitor  is  used  to  display  selected  information.  The  user  interface  contains  two 
medium  format  (at  least  1024x768)  touch  screen  displays,  a  keyboard,  and  a  cursor 
control  device  (e.g.,  a  mouse).  This  section  is  divided  into  two  major  sections  -  the  first 
being  a  description  of  the  left-hand  display  screen  (i.e.  the  navigation  screen)  and  the 
second  a  description  of  the  right-hand  display  screen  (i.e.,  the  task  screen)  The  interaction 
mechanisms  and  tools  associated  with  individual  pages  or  screen  regions  are  described 
under  each  section. 

4. 5.4.6. 1  Navigation  Screens 

The  initial  Navigation  screen  layout  consists  of  a  series  of  condition  and  alarm  indicators 
along  the  top  menu  bar  and  an  elevation  view  of  the  ship. 

Condition  Indicator:  This  is  a  visual  display  tool  that  indicates  the  current  condition  of 
the  ship  and  the  current  hatch/door  conditions.  Ships  condition  indicators  are  only 
illuminated  when  a  condition  is  active.  Only  one  condition  is  active  at  any  given  time. 
Inactive  conditions  appear  unr  illuminated  (i.e.,  grayed-out).  These  indicators  are 
presently  inactive,  but  they  are  included  to  give  the  user  an  idea  how  a  fully  integrated 
console  may  appear. 

Alarm  Indicator:  This  is  a  visual  display  tool  that  indicates  all  alarm  conditions  currently 
present  aboard  ship.  Symbols  include  fire,  flood,  medical,  structural,  machinery,  acoustic, 
and  temperature  alarms.  The  alarm  indicators  are  always  presented  in  the  same  location. 
Inactive  alarms  appear  grayed-out.  Active  alarms  appear  illuminated  with  the  appropriate 
severity  color  code  (red,  yellow,  blue,  or  silver)  as  illustrated  in  Figure  80. 

The  colors  correspond  to  the  severity  of  the  alarm  in  the  following  manner: 

•  RED  -  Alarm  (i.e.  fire) 

•  YELLOW  -  Alert  (i.e.  machinery  out  of  normal  operating  range) 

•  BLUE  -  RSVP  System  Alert  (i.e.  bad  RSVP  sensor) 

•  SILVER  -  Operator  Notification  (i.e.  SSGTG  offline) 


Figure  80  Condition  and  Alarm  Indicators 
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Broadside  Tool:  This  tool  shows  a  broadside  view  of  all  decks  aboard  ship  as  shown  in 
Figure  81 .  Users  are  able  to  point  and  click  on  a  deck  to  select  it.  To  select  a  particular 
compartment,  position  the  mouse  pointer  on  top  any  deck  highlight  in  light  gray,  and 
click  the  mouse  button.  This  will  cause  a  plan  view  of  the  selected  deck  to  be  shown  on 
the  right  hand  side  of  the  Navigation  screen.  When  selected,  the  deck  is  outlined  in  white, 
the  deck  number  appears  to  the  right  of  the  deck  pointer,  and  the  deck  plate  tool  shows 
the  plan  view  of  the  selected  deck.  If  an  event  is  active  in  a  section  of  the  ship,  that 
section  is  filled  with  the  appropriate  severity  color  code  (red,  yellow,  blue,  or  gray).  Note 
that  not  all  compartments  or  decks  are  configured  in  the  software. 


Figure  81  Broadside  Tool 
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Deck  Plate  Tool:  This  tool  shows  a  plan  view  of  a  single  deck  as  shown  in  Figure  82.  To 
select  a  particular  compartment  on  that  deck,  position  the  mouse  pointer  on  top  any 
compartment  on  the  deck  plate  tool  highlighted  in  light  gray,  and  click  the  mouse  button. 
This  will  cause  a  view  of  that  compartment  to  appear  just  left  of  center  toward  the  bottom 
of  the  Navigation  screen.  When  selected,  the  compartment  is  outlined  in  white  and  the 
compartment  tool  shows  the  perspective  view  of  the  selected  compartment. 
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Compartment  Tool:  This  tool  shows  a  perspective  view  of  a  compartment  as  shown  in 
Figure  83.  The  display  is  an  illustration  of  the  compartment  and  objects  representing  the 
sensor  types  located  within  that  compartment.  All  active  objects  are  color  coded  black  to 
indicate  to  users  that  they  can  point  and  click  to  select  it.  Inactive  objects  are  grayed  out. 
When  selected,  the  object  name  appears  near  the  object,  and  the  task  screen  on  the  right 
hand  monitor  shows  all  pertinent  details  for  that  object.  If  an  event  is  active  for  an  object, 
that  object  is  filled  with  the  appropriate  severity  color  code  (red,  yellow,  blue,  or  gray).  In 
addition,  hazard  icons  appear  below  the  compartment  name  to  indicate  the  events  that  are 
active  in  the  compartment  (e.g.,  if  fire  is  present,  a  smaller  version  of  the  fire  icon  that 
appears  in  the  hazard  indicator  is  displayed  underneath  to  the  compartment).  To  obtain 
more  information  about  a  particular  alarm  condition,  move  the  mouse  curser  over  the 
sensor  icon  of  interest  on  the  compartment  view  and  click  the  mouse  button,  and  the  data 
screen  associated  with  that  sensor  will  appear  on  the  right  hand  monitor.  For  example,  if 
the  user  selects  one  of  the  machinery  icons  from  the  compartment  view  of  the  Navigation 
screen,  the  software  will  automatically  display  the  Machines  page  associated  with  the 
machine  in  the  compartment  the  sensor  is  monitoring.  The  same  applies  to  the  other  icons 
such  as  temperature,  crew,  environmental  (video),  crew,  structure,  and  hatch.  When 
sensors  provide  an  alert  or  alarm,  an  icon  corresponding  to  the  sensor  is  displayed 
indicating  the  alarm  the  position  of  the  alarm.  For  example,  a  fire  alarm  may  be  generated 
by  two  of  the  four  sensors  in  the  compartment.  The  sensor  icons  creating  that  alarm  will 
be  visible  to  indicate  the  fire  is  likely  localized  to  that  physical  area. 


Figure  83  Compartment  Tool 
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Layer  Tool:  To  prevent  clutter  a  layering  tool  has  been  included  in  the  bottom  right  hand 
comer  of  the  navigation  screen.  Six  layers  are  presented  -  temperature,  crew,  camera 
(environment),  machines,  structure,  and  hatches/doors.  A  button  is  presented  to  hide  or 
show  all  selectable  objects  of  that  type  for  each  compartment  shown.  To  show  or  hide 
any  of  these  sensor  icons,  position  the  mouse  pointer  over  the  icon  associated  with  the 
sensor  type  you  wish  to  show  or  hide  in  the  lower  right  hand  comer  of  the  Navigation 
screen  and  click  on  it  with  the  mouse  button.  For  example,  Figure  84shows  all  sensor 
icons  hidden  with  the  exception  of  the  machinery  sensor  icon. 
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4. 5. 4. 6. 2  Task  Screens 

The  task  screens  contain  details  about  the  compartment  selected  in  the  navigation  tool. 
Task  screens  consist  of  the  following  types: 

•  OVERVIEW  —  No  information  is  currently  presented 

•  EVENTS  -  detailed  information  on  the  alarm  and  alert  events  for  the  ship 

•  STRUCTURE  -  hull  stress  and  strain  in  a  compartment 

•  MACHINES  -information  on  the  machines  in  a  compartment 

•  ENVIRONMENT  -  environmental  data  in  a  compartment 

•  CREW  -  personnel  information  in  a  compartment 

•  SYSTEM  -  detailed  information  of  the  RSVP  system  components  in  a 
compartment 

General  Arrangement :  The  general  arrangement  of  the  task  screens  consists  of  a  menu 
bar  across  the  top,  a  data  region  where  data  associated  with  that  screen  type  is  displayed 
directly  below  the  menu  bar,  a  document  region  to  the  right  of  the  data  region,  and  an 
event  table  region  at  the  bottom  -  Figure  85.  It  is  possible  to  “navigate”  from  one  task 
screen  to  another  by  using  the  mouse  to  click  on  the  corresponding  tab  button  on  the 
menu  bar  at  the  top  of  the  task  screen.  The  type  of  data  displayed  in  the  data  region  of  the 
task  screen  is  unique  to  each  page  and  is  discussed  is  the  appropriate  sections  below.  The 
document  region  is  not  functional  at  this  time.  In  general  the  task  screens  are  displayed 
through  the  use  of  pull  down  menus  and  page  buttons. 
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Figure  85  General  Arrangement  of  Task  Screen 


The  event  table  displays  all  pertinent  event  information  including  the  event  name,  time  of 
initiation,  priority  level,  source  of  event  trigger,  and  status  of  event.  Table  entries  are 
presented  by  chronology.  (Figure  86). 


Figure  86  Event  Table 


The  event  table  region  also  contains  four  indicators  in  the  lower  right  hand  comer  of  the 
screen  that  convey  to  the  user  the  number  of  active,  unacknowledged  events  for  each 
category.  A  red/yellow/blue/silver  bar  with  a  #  indicates  there  are  #  active 
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alarms/alerts/system  alerts/notifications.  If  there  are  no  events  of  a  certain  type  the 
indicator  number  will  display  “0”.  Indicators  always  appear  in  the  same  location.  The 
pencil  icons  on  the  far  right  are  currently  inactive.  Their  intent  is  to  allow  the  operator  to 
make  notes  on  an  event  such  as  acknowledging  the  alert  or  dispatch  of  repair  team. 

4. 5. 4. 6. 3  Event  Data  Pages 

This  page  provides  detailed  event  information  on  events  that  have  occurred.  A  standard 
set  of  information  is  presented  including  event  location,  duration,  symptoms,  diagnosis, 
confidence,  prognosis,  and  impact  -  Figure  87.  All  sensors  contributing  to  an  event  are 
listed  after  the  “Description”  label.  The  description  name  is  color  coded  to  indicate  the 
severity  level  of  the  sensor  event.  The  current  sensor  reading  is  displayed  next  to  the 
symptom  name  and  is  followed  by  the  time  of  event  initiation.  Depending  on  the 
subsystem  not  all  of  the  fields  below  the  Symptom  are  populated  with  data. 

The  first  item  in  the  Event  Table  is  the  default  event  page  displayed  when  the  “Events” 
button  is  selected.  The  page  navigation  tool  cycles  through  multiple  pages  of  a  particular 
summary  as  necessary.  To  display  another  event  in  the  event  summary  page  users  must 
select  a  new  event  from  the  Event  Table  or  use  the  scroll  bar. 
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4. 5. 4. 6.4  Structure  Data  Pages 

This  page  shows  a  visualization  tool  that  displays  a  network  of  sensors  to  show  hull- wide 
strain  levels  with  port,  starboard  and  keel  views  as  shown  in  Figure  88.  Events  are  color 
coded  by  severity  and  intensity.  When  the  strains  are  normal  the  network  appears  black. 
Events  are  color  coded  by  severity  and  intensity.  Hue  indicates  severity  level  while 
saturation  indicates  intensity  level.  Below  the  visualization  tool  are  three  buttons  (Strain, 
Seaway  Shock,  and  High  G  Shock).  Selecting  any  of  these  buttons  will  provide  you  with 
more  detailed  information  about  the  parameter  selected.  Once  one  of  these  buttons  has 
been  selected,  a  page  displaying  detailed  information  related  to  that  parameter  is 
displayed. 


Figure  88  Hull  Stress  Overview  Page 
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4.5.4.6.4.1  Machinery  Data  Pages 

This  page,  shown  in  Figure  89,  presents  an  overview  of  the  critical  equipment  classes  for 
each  of  the  major  ship  systems  -  electrical,  propulsion,  auxiliary,  and  damage  control.  At 
this  time  only  the  SSGTGs  in  the  electrical  machinery  group  are  monitored.  In  a  final 
system,  operators  would  be  able  to  navigate  to  different  systems  and  subsystems  from 
tins  page  using  the  pull-down  menus  in  the  header.  Currently  only  one  SSGTG  is 
implemented,  therefore  the  other  two  SSGTGs  are  grayed  out.  Once  the  SSGTG  has  been 
selected,  the  data  for  the  machine  is  presented  in  column  format.  The  machine  name 
button  allows  the  operator  to  drill-down  to  detailed  information  that  item.  Health  and 
operating  status  statements  also  are  presented  for  each  machine. 


Figure  89  Machinery  Subsystem  Overview  Page 


Once  a  machinery  button  1ms  been  selected,  a  graphical  representation  of  the  machine  is 
displayed,  as  shown  in  Figure  90,  along  with  high-level  data  parameters.  Next  to  each  of 
the  high  level  parameters  is  the  current  reading  and  a  trend  arrow  indicating  if  levels  are 
steady,  increasing  or  decreasing,  or  rapidly  increasing  or  rapidly  decreasing.  A  dash 
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indicates  steady  state,  a  single  up  or  down  arrow  indicates  levels  are  steadily  increasing 
decreasing,  and  a  double  arrow  up  or  down  indicates  levels  are  rapidly  increasing  or 
decreasing. 

The  names  for  the  specific  components  of  the  machine  (i.e.,  generator,  reduction  gear, 
and  engine/accessory  gear  box)  displayed  above  the  high  level  data  are  buttons.  When 
selected,  these  buttons  open  pages  with  detailed  information  for  that  particular 
component.  The  machinery  detail  pages  are  arranged  in  column  format  and  include  the 
current  value,  a  relative  scale  (i.e.,  no  scale  is  provided),  a  measure  of  the  absolute  rate  of 
change,  and  the  relative  rate  of  change.  The  user  can  page  through  detailed  information 
for  that  component  as  shown  in  Figure  91.  A  pull  down  menu  allows  the  user  to  switch 
between  generator,  reduction  gear,  and  engine/accessory  gearbox  detailed  data.  The  user 
can  page  through  to  view  trend  data  or  access  trend  data  directly  using  a  pull  down  menu 
as  shown  in 

Figure  92.  An  example  of  a  trend  data  page  is  shown  in  Figure  93. 


Figure  90  SSGTG  Overview  Page 
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Figure  93  SSGTG  Trend  Data  Page 
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4.S.4.6.5  Environment 


This  page  presents  a  high  level  view  of  all  measured  environmental  conditions  in  the 
active  compartment  in  column  format  including  condition  name  and  values  for  each 
condition  as  shown  in  Figure  94,  More  detailed  information  for  each  environmental 
condition  can  be  viewed  by  positioning  the  mouse  button  on  top  of  the  environmental 
condition  name  of  interest  and  clicking.  Environmental  detail  pages  are  arranged  in 
column  format  and  include  the  current  value  and  a  relative  scale  (i.e.,  no  scale  is 
provided)  as  shown  in  Figure  95.  The  user  can  page  through  detailed  information  for  that 
sensor.  A  pull  down  menu  allows  the  user  to  switch  between  sensors. 


Figure  94  Environmental  Overview  Page 
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Figure  95  Environmental  Detail  Page 
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4.S.4.6.6  Crew 

This  page  presents  a  list  of  all  personnel  in  the  active  compartment  as  shown  in  Figure 
96.  A  table  is  used  to  display  rank  and  name,  health  status,  and  station  information  for 
each  person.  Each  name  in  column  1  is  also  a  button  that  navigates  to  individual  crew 
details.  When  events  are  active  for  a  crewmember,  the  name  is  color-coded  to  reflect  the 
appropriate  severity  level.  When  a  name  button  is  selected,  the  system  presents  detailed 
information  about  that  individual  as  shown  in  Figure  97.  The  crewmember’s  name  and 
navigation  tool  is  displayed  below  the  compartment  name  in  the  header.  Next,  health 
information  and  panic  button  status  are  presented  under  the  header  line.  If  health  and 
panic  button  status  are  other  than  OK,  the  statement  is  color-coded  to  reflect  the  severity 
of  the  problem.  Information  about  the  individual’s  station  and  position  and  motion  status 
also  is  displayed.  The  Details  table  displays  a  list  of  sensor- specific  parameters,  their 
current  readings  -  in  both  text  and  graphic  format. 


Figure  96  Crew  Overview  Page 
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Figure  97  Crew  Detail  Page 
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4.S.4.6.7  System 

This  page  presents  a  graphical  representation  of  the  RSVP  system  components  within  the 
active  compartment  as  shown  in  Figure  98.  In  a  final  system  this  field,  these  task  screens 
would  only  be  viewable  by  maintenance  activities.  They  are  not  intended  for  general  use 
by  the  operator.  System  components  have  unique  iconic  representations  that  can  be 
selected  to  drill-down  to  more  detailed  information  about  the  selected  Personnel,  Access 
Point,  Sensor  Cluster,  SHM,  or  ICHM.  In  some  cases,  additional  sensors  located  within 
the  compartment  may  be  available  for  viewing  by  paging  to  additional  pages.  Users  can 
filter  displayed  content  by  selecting  or  de-selecting  toggle  buttons  from  the  layer  tool  in 
the  bottom  right-hand  comer  of  the  page.  When  a  toggle  button  is  on,  associated  icons  are 
visible  on  the  graphic. 

Each  Personnel,  Access  Point,  Sensor  Cluster,  SHM,  or  ICHM  detail  page  is  arranged  in 
column  format  and  includes  a  listing  of  the  parameters  measured  by  the  sensor  and  the 
current  value  as  shown  in  Figure  99.  A  drop  down  menu  provides  the  user  with  the  ability 
to  select  detail  information  for  any  of  the  sensors  within  the  selected  compartment. 


Figure  98  System  Components  in  Compartment 
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5.0  Demonstrations 

5.1  LBES 

The  purpose  of  the  LBES  demonstration  was  to  perform  a  bottom-to-top  Verification  and 
Validation  (V&V)  of  RSVP  system  component  functionality  and  system  integration 
while  installed  on  the  LBES  DG-51  class  engine  plant.  Assessment  of  data  validity,  data 
accuracy,  and  optimum  system  configuration  was  not  performed  in  this  demonstration. 
The  installation,  testing  and  removal  of  the  RSVP  equipment  occurred  January  19 
through  February  1, 2001 

5.1.1  Primary  Goals: 

1 .  Complete  subsystem  and  system  integration  checkout  and  operation. 

a.  V&V  of  each  subsystem. 

b.  All  subsystems  functioning  concurrently. 

c.  Subsystems  functionally  integrated. 

2.  Validate  operation  and  interface  with  Navy  ship  machinery  and  engine  plant 
systems. 

a.  Sensor  data  acquisition  and  information  fusion  of  available  environmental 
machinery  and  structural  data. 

b.  ICHM  and  SHM  operation  and  interface/installation  on  the  Allison  K1 7 
Generator  set. 

c.  Wireless  data  transmission. 

d.  HCI  functionality  utilizing  available  sensor  data  and  information  fusion. 

3.  Mitigate  risk  of  major  demonstrations 

a.  Resources  to  modify  or  repair  will  be  limited  during  shipboard  tests. 

5.1.2  Approach: 

1 .  Install  fully  constructed  and  fully  functional  Environmental  Sensor  Cluster, 
Machinery  ICHMs  and  SHMs,  and  Access  Points  (APs)  into  a  configuration  as 
similar  as  possible  to  the  planned  CG-47  class  installation. 

2.  Install  the  Watchstation  on  the  LBES  and  run  the  RSVP  HCI  software. 

3.  Connect  the  Watchstation  to  the  APs  using  an  RSVP  Local  Area  Network  (LAN). 

4.  Verify  RSVP  components  function  as  intended. 

a.  SC/ICHM/  SHM  sensors  acquire  data. 

b.  SC/ICHM/SHM  data  fusion  performs  as  designed. 

c.  SC/ICHM/SHM  data  is  successfully  wirelessly  transmitted  to  APs. 

d.  AP  data  acquisition  software  functions  as  designed. 

e.  AP  data  fusion  software  functions  as  designed. 

f  APs  successfully  transmit  the  correct  information  to  the  Watchstation  over 
the  LAN. 

g.  HCI  software  receives,  displays  and  reacts  to  AP  information  as  designed. 
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5.1.3  Equipment 

The  LBES  demonstration  consisted  of  the  following  system  components: 

•  Watchstation  -  1 

•  APs  -  4 

o  APCM-4 
o  Cameras  -  4 

•  Environmental  Clusters  -  1 0 

•  Hubs  -  1 

•  Machinery  Health  Monitoring  System  -  1 

o  SHM  -  1 
o  ICHM-4 

o  Instrumentation  Box  -  1 
o  Power  Supply  Box  -  1 

5.1.4  Normal  Operation  Tests 

Normal  operation  tests  were  executed  to  verify  that  the  RSVP  system  and  its 
components  were  operating  in  a  proper  fashion.  The  following  sections  describe  the 
various  test  procedures  that  were  executed. 


5.1. 4.1  Environmental  Sensor  Cluster  (ESC) 

The  ESC  is  a  self-contained  unit  that  senses  its  local  environmental  situation, 
autonomously  determines  if  some  level  of  casualty  situation  exists,  and  reports  the 
information  to  an  AP.  The  ESC  monitors  the  following  parameters: 

1 .  Habitation  temperature 

2.  Casualty  temperature  range 

3.  Smoke  density 

4.  Carbon  monoxide  . 

5.  Flooding 

6.  Hatch  closure 

7.  Compartment  pressure 

8.  Oxygen 

9.  Humidity 

10.  Sound 
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An  ESC  is  considered  operating  properly  if  the  ESC  can  successfully  perform  all  of  the 
following  scenarios. 

Scenario  1 :  ESC  Acquisition 
Scenario  2.  ESC  Data  Uplink 
Scenario  3.  ESC  Sound  Uplink 
Scenario  4.  Retrieve  ESC  Diagnostic  Data 
Scenario  5.  Retrieve  ESC  Calibration  Data 
Scenario  6.  Retrieve  ESC  Threshold  Data 
Scenario  7.  Retrieve  ESC  Location  Data 
Scenario  8.  Retrieve  ESC  Frequency  Data 
Scenario  9.  Change  Single  ESC  Threshold 
Scenario  10.  ESC  Downlink 
Scenario  1 1 .  Single  ESC  Kickoff 
Results: 

All  10  ESC  units  passed  the  1 1  scenarios  described  above.  Initially,  there  was  a  software 
error  for  the  Scenario  5:  Retrieve  Calibration  Data  test.  A  solution  was  determined  and 
implemented.  Based  on  the  solution  all  of  the  ESC  passed  all  1 1  scenarios. 

5.1. 4.2  Machinery  HMS  (ICHM  and  SHM) 

The  HMS  is  considered  operating  properly  if  after  installed  on  the  SSGTG,  the  following 
steps  can  successfully  be  performed  autonomously; 

•  The  ICHM  and  SHM  boot  up  when  connected  to  power 

•  Preinstalled  operational  configurations  are  established 

•  Communications  are  established  between  the  SHM  and  ICHM 

■  Radio  link  are  established  and  maintained 

■  Communication  messages  are  sent  and  received 

•  The  ICHM  begins  data  collection,  processing  and  reporting  data/information  to 
the  SHM. 

•  The  SHM  receives  information  from  the  ICHM  in  the  form  of  messages,  converts 
the  messages  from  TCP/IP  to  NDDS  format  and  transmits  to  the  AP 

•  The  SHM  services  requests  from  the  Watchstation  through  the  AP  and  provides 
data/information  in  response  to  operators  requests. 

General  Results: 

The  four  ICHMs  and  SHM  were  installed  on  the  K17  SSGTG  on  the  LBES  and  stepped 
through  a  series  of  tests  to  verify  proper  operation  and  functionality  according  to  the  five 
(5)  test  requirements  identified  above.  Autonomous  operations  of  the  ICHMs  and  SHM 
were  remotely  monitored  using  several  communication  and  software  debug  programs  that 
allowed  monitoring  of  the  ICHM  and  SHM  operations  without  direct  interaction. 

Specific  tests  and  results  are  as  follows; 
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Installation  -  install  and  operate  all  of  the  HMS  hardware  and  software  on  the  K17 
SSGTG  at  LBES  prior  to  ship  installation  to  ensure 

the  proper  installation  procedures  are  established  and  documented 
the  HMS  does  not  interfere  with  the  SSGTG  operation 
the  HMS  operates  properly  when  installed  on  the  SSGTG 

Results  -  N SWCCD  code  9332  verified  the  installation  procedures  ands  installed  the 
HMS  hardware.  The  SSGTG  was  run  over  the  course  of  several  days,  the  HMS  had  no 
impact  on  the  SSGTG  operation.  Based  on  the  test  and  hardware  installed,  installation 
procedures  were  established  by  the  NSWCCD  Gas  Turbine  Life  Cycle  code  in 
accordance  with  GTB14. 

Power  On  -  test  for  autonomous  boot  operation 

Results  -  all  ICHMs  and  SHM  booted  properly  in  accordance  with  preinstalled  operating 
configuration  files 

Communications  Link  (SHM  to  ICHM)  -  determine  if  bi-directional  communications 
are  reliably  and  adequately  established  in  the  LBES  environment 

Results  —  communication  between  the  ICHMs  inside  and  outside  the  SSGTG  module 
were  automatically  established  and  maintained  with  the  SHM  located  in  the  RSVP  HMS 
power  supply  enclosure 

Communications  Link  (SHM  to  WS)  -  determine  if  bi-directional  communications, 
including  multiple  protocol  translations,  from  the  SHM  through  the  AP  to  the  WS  and 
vice  versa  WS-AP-SHM  are  reliably  and  adequately  established  in  the  LBES 
environment. 

Results  -  communication  between  the  SHM  and  WS  (TCP  Server  (SHM)  to  TCP  Client 
(SHM)  to  NDDS  Server  (SHM)  to  NDDS  Client  (WS))  and  WS  to  SHM  communication 
(NDDS  Client  (WS)  to  NDDS  Server  (SHM)  to  TCP  Client  (SHM)  to  TCP  Server  (SHM)) 
were  automatically  established  and  maintained.  Publications  and  subscriptions  were 
started  and  stopped  using  the  Machine/NDDS  interface  (MNI)  client  test  program  to 
verify  operation 

Sensor  Connectivity  and  Operation  -  verify  sensor  connectivity  and  the  accurate 
collection  and  processing  of  data  from  all  sensors  connected  to  the  ICHMs 

Results  -  Each  sensor  signal  value  was  compared  to  locally  available  readouts  for  the 
same  parameters.  Some  variation  in  electrical  parameters  were  identified.  Variations  were 
attributed  to  filter  card  settings  and  adjustment  of  calibration  files  -  particularly  electrical 
CT’s.  On-site  adjustments  were  made  correcting  variations  for  a  majority  of  the 
differences.  Post  LBES  tuning  of  the  filter  cards  will  be  conducted  prior  to  the  Ship 
install  to  correct  remaining  variations. 
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Sensor/Parameter  Data  Mapping-  verify  data/information  from  the  ICHMs  and  SHM 
is  correctly  being  sent  to  the  WS 

Results  -  Using  the  remote  DIVA  program,  parameters  and  messages  from  both  the 
ICHMs  and  SHM  were  monitored  and  corroborated  with  the  messages  sent  to  the 
watchstation.  Sensor  parameters  generated  by  the  ICHMs/SHM  and  respective  messaging 
were  verified. 

Data  Mapping  to  Watchstation-  similar  to  that  described  above,  verify 
data/information  from  the  ICHMs  and  SHM  is  correctly  being  displayed  at  the  WS  and 
operator  requests  are  executed  with  expected  results. 

Results  -  Using  the  remote  DIVA  program,  parameters  and  messages  from  both  the 
ICHMs  and  SHM  were  monitored  for  correct  display  at  the  watchstation.  The  User 
Interface  (UI)  was  exercised  and  discrepancies  identified.  Several  were  corrected  during 
the  course  of  the  test.  Remaining  corrections  are  to  be  accomplished  off-site  prior  to  the 
ship  install. 

5.1. 4.3  Radio  Bit  Error  Rate  (BER)  Testing 

BER  tests  were  run  while  the  equipment  was  install  on  the  LBES  plant.  The  initial  BER 
test  indicated  a  BER  of  12%.  12%  is  significantly  higher  than  was  expected,  A  BER  of 
<l%was  anticipated.  Draper  engineers  investigated  the  radio  boards  and  found  the  new 
board  assemblies  had  a  slightly  lower  attenuation  than  the  previous  assemblies  even  with 
the  same  component.  The  engineers  changed  a  resistor  value  to  better  align  the  radio.  The 
radio  was  further  tested  and  found  to  have  BER  of<l%.  All  the  radios  were  modified 
during  the  LBES  installation  period  and  the  BER  tests  were  rerun  yielding  BER  results  of 
<1%. 

5.1 .4.4  APs 

The  AP  startup  and  network  software  is  designed  so  that  AP,  when  initially  turned  on, 
will  automatically  initiate,  configure  and  establish  communications  with  the  other  APs  in 
the  same  compartment.  If  the  a  particular  AP  is  the  first  to  be  powered  on  in  a 
compartment  it  then  becomes  the  Primary  AP  and  controls  all  the  data  flow  in  and  out  of 
the  compartment. 

Results:  All  4  APs  successfully  performed  the  above  requirements 

5.1.4.5  Algorithms 

5.1. 4.5.1  Environmental  Sensor  Cluster 
Fire: 

The  environmental  sensor  cluster  typically  samples  its  sensors  once  a  second  and 
transmits  a  data  message  every  10  seconds.  If  a  cluster  detects  rapid  changes  and/or 
thresholds  have  are  exceeded  then  the  cluster  will  transmit  the  data  to  the  AP  at  a  rate  of 
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once  a  second  for  further  processing.  When  the  source  of  the  changes  has  dissipated  the 
sensor  cluster  return  to  its  normal  mode  of  operation. 

Results:  Due  to  limited  capability  of  the  LBES  facility  the  fire  algorithm  was  reduced  to  a 
temperature  reading.  Once  the  Sensor  Cluster  had  detected  this  event  it  behaved  similarly 
as  if  the  real  fire  algorithm  were  implemented.  The  2  ESC  units  performed  the  fire 
demonstration  as  planned. 

Flood: 

Due  to  the  limited  capabilities  of  LBES  facility,  the  flooding  algorithm  will  comprise  of 
multiple  sensor  clusters  monitoring  the  water  level  of  buckets  of  water.  The  sensor  cluster 
typically  samples  its  flooding  sensor  once  a  second  and  transmits  a  data  message  every 
10  seconds.  If  a  cluster  detects  rapid  change  and/or  a  “high”  level  the  cluster  will  transmit 
the  data  to  the  AP  at  a  rate  of  once  a  second  for  further  processing.  AP  algorithms  will 
provide  higher  level  processing  to  determine  whether  or  not  to  issue  an  alarm 
Results:  The  2  ESC  units  used  during  the  demonstration  operated  as  designed. 

High  Temperature: 

The  high  temperature  algorithm  has  been  designed  to  indicate  a  single  point  temperature 
threshold  that  has  been  exceeded.  If  a  cluster  detects  a  rapid  change  and/or  a  “high”  level 
the  cluster  will  transmit  the  data  to  the  AP  at  a  rate  of  once  a  second  for  further 
processing.  AP  algorithms  will  provide  higher  level  processing  to  determine  whether  or 
not  to  issue  an  alarm 

Results:  The  2  ESC  units  used  during  the  demonstration  operated  as  designed. 
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Machinery  HMS  (ICHM  and  SHM)  LBES  Testing 
5.1.4.5.1.1  Testing  Approach 

Three  classes  of  machinery  HMS  faults  were  simulated  as  part  of  the  LBES  testing. 
These  faults  were 

1 .  Component  iaults  -  detect  deterioration  of  key  SSGTG  mechanical  and  electrical 
components  (bearings,  gears,  windings) 

2.  Limit  faults  -  notification  to  the  operator  that  and  out-of-limit  condition  exists 
(voltage,  current,  vibration) 

3.  HMS  faults  -  self  monitoring  provide  operator  with  health  of  monitoring  system 
(ICHM,  accelerometers) 

Scripted  scenarios  run  for  each  ICHM/class  of  fault  are  described  below; 

ICHM  #1  Generator  Electrical 


Component  faults  -  Modify  associated  processed  data  at  ICHM  level  to  trigger 
generation  of  alert  and  alarm  messages. 

1)  RECTIFIER_DIODE_COMP_FAULT 

2)  STATOR  WINDING  COMP  F AULT 

3)  FIELD JWINDING_COMP_FAULT 


Limit  faults  -  Running  plant  or  inject  voltage  signal  directly  into  ICHM.  Adjust 
channel  sensitivity  to  increase  or  decrease  associated  parameter  level  reported  by 
ICHM  and  trigger  alert  and  alarm  generation. 

1)  VA  RMS  LIMIT  FAULT  -  high  or  low 

2)  VB_RMS_LIMIT_F AULT  -  high  or  low 

3)  VC  JIMS JLIMITF  AULT  -  high  or  low 

4)  VOUT  RMS  LIMIT  FAULT  -  high  or  low 

5)  VEXC_RMS_LIMIT_FAULT  -  high  or  low 

6)  IA_RMS_LIMIT_FAULT  -  high 

7)  IB_RMS_LIMIT_FAULT  -  high 

8)  IC  RMS  LIMIT  FAULT  -  high 

9)  IOUT_RMS_LIMIT_FAULT  -  high 

10)  IEXC  JIMS  JJMITJF  AULT  -  high 

1 1)  GEN_FREQ_LIMIT_FAULT  -  high  or  low 

12)  POUT  LIMIT  FAULT  -  high 

System  faults  —  Adjust  channel  sensitivity  to  increase  reported  ICHM 
temperature  and  trigger  system  alert  generation 
1)  ICHM  SYSTEM  FAULT  -  high 


217 


NSWCCD-TR-2003/02 


1CHM  #2  Generator  Mechanical 


Component  faults  -  Modify  associated  processed  data  at  ICHM  level  to  trigger 
generation  of  alert  and  alarm  messages. 

1)  DE  BEARING  COMP  FAULT 

2)  PMABEARINGCOMPFAULT 

Limit  faults  -  Running  plant  or  inject  voltage  signal  directly  into  ICHM.  Adjust 
channel  sensitivity  to  increase  or  decrease  associated  parameter  level  reported  by 
ICHM  and  trigger  alert  and  alarm  generation. 

1)  ARMS_DE_1_LIMIT_FAULT  -  high 

2)  ARMS_PMA_1_LIMIT_F  AULT -high 

3)  ARM S_DE_2_LIMIT_F AULT  -  high 

4)  ARMS_PMA_2_LIMIT_FAULT -  high 

System  faults  -  Adjust  channel  sensitivity  to  increase  reported  ICHM  or 
accelerometer  temperature  and  trigger  system  alert  generation.  Disconnect 
accelerometers  to  trigger  accelerometer  system  alert  or  alarm. 

1)  ICHM  SYSTEM  FAULT  -  high  temp 

2)  ADEISYSTEMFAULT  -  temp  high,  shorted  or  disconnected 

3)  A_PMA_1_SYSTEM_FAULT  -  temp  high,  shorted  or  disconnected 

4)  A_DE_2_SYSTEM_FAULT  -  temp  high,  shorted  or  disconnected 

5)  A_DE_2_SYSTEM_FAULT  -  temp  high,  shorted  or  disconnected 


ICHM  #3  Reduction  Gear  Box 


Component  faults  -  Modify  associated  processed  data  at  ICHM  level  to  trigger 
generation  of  alert  and  alarm  messages. 

1)  HS_DE_BEARING_COMP_FAULT 

2)  HS  NDE  BEARING  COMP  FAULT 

3)  LS  DE  BEARING  COMP  FAULT 

4)  LS_NDEJBEARING_COMP_FAULT 

5)  RBG  GE AR_F AULT 


Limit  faults  —  Running  plant  or  inject  voltage  signal  directly  into  ICHM.  Adjust 
channel  sensitivity  to  increase  or  decrease  associated  parameter  level  reported  by 
ICHM  and  trigger  alert  and  alarm  generation. 

1)  ARMSHSJDELIMITFAULT  -  high 

2)  ARMSHSJNDELIMITFAULT  -  high 

3)  ARMS  LS  DE  LIMIT  FAULT  -  high 

4)  ARMS_LS_NDE_LIMIT_FAULT  -  high 
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System  faults  -  Adjust  channel  sensitivity  to  increase  reported  ICHM  or 
accelerometer  temperature  and  trigger  system  alert  generation.  Disconnect 
accelerometers  to  trigger  accelerometer  system  alert  or  alarm 

1)  ICHM  S  Y  STEMF  AULT  -  high  temp 

2)  A_HS_DE_SYSTEM_FAULT  -  temp  high,  shorted  or  disconnected 

3)  A_HS_NDE_SYSTEM_FAULT  -  temp  high,  shorted  or  disconnected 

4)  A_LS_DE_SYSTEM_FAULT  -  temp  high,  shorted  or  disconnected 

5)  A_LS_NDE_SYSTEM_FAULT  -  temp  high,  shorted  or  disconnected 


ICHM  #4  Accessory  Gear  Box 

Component  faults  -  Modify  associated  processed  data  at  ICHM  level  to  trigger 
generation  of  alert  and  alarm  messages. 

1)  COMP_BEARING_COMP_FAULT 

2)  TOWERJBEARINGCOMPFAULT 

Limit  faults  -  Running  plant  or  inject  voltage  signal  directly  into  ICHM.  Adjust 
channel  sensitivity  to  increase  or  decrease  associated  parameter  level  reported  by 
ICHM  and  trigger  alert  and  alarm  generation. 

1)  ARMS_ENGINE_LIMIT_FAULT  -  high 

2)  ARMS_AGBX_LIMIT_FAULT  -  high 

3)  ARMSAGBYJLIMITFAULT  -  high 

4)  ARMS_AGBZ_LIMIT_FAULT  -  high 

5)  T_MODULE_LIMIT_FAULT  -  high 

System  faults  -  Adjust  channel  sensitivity  to  increase  reported  ICHM  or 
accelerometer  temperature  and  trigger  system  alert  generation.  Disconnect 
accelerometers  to  trigger  accelerometer  system  alert  or  alarm 

1)  ICHMSYSTEMJFAULT  -  high  temp 

2)  A_ENG_SYSTEM_FAULT  -  temp  high,  shorted  or  disconnected 

3)  A_AGBX_SYSTEM_FAULT  -  shorted  or  disconnected 

4)  AAGBYSYSTEMFAULT  -  shorted  or  disconnected 

5)  A_AGBZ_SYSTEM_FAULT  -  shorted  or  disconnected 
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These  scenarios  were  simulated  by  artificially  altering  data  as  it  was  collected  using  the 
ICHM  script  file.  This  was  done  prior  to  execution  of  the  analysis/  feature  extraction 
routines.  In  most  cases  this  was  done  adding  gain  to  the  signal.  For  the  limit  faults,  this 
was  straight  forward,  simply  increasing  the  level  of  the  measured  parameter  in  question, 
until  a  preset  limit  was  exceeded.  For  the  RGB  component  fault,  specific  frequencies 
associated  with  the  gear  geometries  and  operating  conditions  were  altered  to  simulate  an 
evolving  gear  defect  and  stimulate  the  data  processing  and  feature  extraction  capabilities 
of  ICF1M  #3.  The  simulated  gear  vibration  signatures  would  not  be  detected  using 
standard  RMS  vibration  measurements,  thereby  demonstrating  the  advanced  warning 
analysis  capabilities  of  the  HMS.  HMS  faults  were  simulated  by  loosening  the  cable  to 
each  accelerometer  to  simulate  a  faulty  sensor  or  wire.  Communication  faults  were 
simulated  by  turning  the  ICHM  and/or  SHM  off. 

5.1.4.5.1.2  Testing  Process 

The  following  is  a  summary  of  how  the  machinery  scenarios  were  implemented  and  the 
verification  process  for  the  simulated  faults.  Timely  detection  of  the  simulated  faults  at 
the  ICHM,  generation  of  the  corresponding  fault  message  receipt  of  the  fault  message  at 
the  SHM  and  accurate  display  of  the  condition  at  the  Watchstation  formed  the  basis  of 
the  test  criteria.  Testing  was  conducted  in  two  phases.  Phase  one  focused  on  the  HMS 
system  only.  Generation  and  receipt  of  the  proper  message  by  the  ICHM  and  SHM 
respectively  was  verified  by  using  diagnostics  software  resident  on  the  SHM.  Virtual 
Network  Computing  (VNC)  software  allowed  the  test  engineer  to  access  and  run 
programs  on  both  the  SHM  and  ICHMs  using  a  laptop  and  wireless  Network  Interface 
Card  (NIC).  This  configuration  is  shown  in  Figure  100 


Proxim  6303  Design-In 
Radio  -  Open  Air  Std 


ffu~ ^ 


i 


onitors  ICHM  and  SHM 


Startup,  Operation,  Communication 
System  Test  and  Debugging 

\'m  W 

1  ICHM/SHM  Programming,  setup 

Figure  100  ICHM  and  SHM  Test  Software/Laptop 
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In  this  maimer,  the  test  engineer  was  able  to;  review  the  ICHM  process, 
ICHM/SHM/NDDS  communication  interface  and  messaging  in  ‘real  time’  in  the  NDDS 
Parameter  Data  Structure  Display.  As  shown  in  Figure  101  the  left  side  of  the  display  will 
show  what  ICHMs  are  connected  and  communicating  with  the  SHM.  The  right  hand  side 
of  the  display  shows  the  messages  the  Watchstation  is  subscribed  to.  Since  the  watch 
station  is  always  attempting  to  subscribe  to  the  alert  and  alarm  messages,  any 
subscriptions  present  on  the  right  hand  side  verifies  that  the  SHM  is  communicating  with 
the  access  point.  Phase  two  involved  verification  that  the  alert  and  alarm  messages  sent 
by  the  SHM  to  the  Watchstation  were  display  accurately  in  a  timely  manner. 


Figure  101  SHM  Connections  Display 
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Several  additional  debug  ‘windows’  that  supported  detailed  assessment  and 
troubleshooting  during  LBES  testing  are  identified  in  Table  32  and  shown  in  Figure  102, 
Figure  103,  Figure  104,  Figure  105,  and  Figure  106. 


Table  32  HMS  Debug  Windows 


"Header  Watcher" 


"Parameter  Data  Structure  Display" 


"NDDS  Parameter  Data  Structure 
Display"  _ 


"Info  Display" 


"Debug  Display" 


displays  the  message  headers  that  each 
ICHM  is  sending  the  SHM 


displays  all  of  the  parameter  data  that  each 
ICHM  is  generating. _ 


displays  all  of  the  generated  fault  data 


displays  all  of  the  parameters  sent  over 
NDDS  to  the  Watchstation  by  the  SHM. 


displays  information  messages  that  are  put 
into  the  ICHM  processing  script  by  the 
programmer  as  diagnostic  information. 

This  allows  rapid  identification  of  the 
current  location  within  the  ICHM 
process/diagnostic  script. _ 


displays  a  real-time  running  display  of  the 
ICHM  processing  script. 


ICHM  Message  Header  Watcher 


ICHM  1 


ICHM  2 


ICHM  3 


ICHM  4 


!  98d78293O.0:32;2:1 .0,306,1 ,1/29/01  3:42:10  PM: 


8;980782936;0;32;2;1  ;0;306;1  ;1  /29/01  3:42:16  PM;1/29/01 
8;980782938;0;32;2;1  ;0;306;1  ;1  /29/01  3:42:18  PM  ,1/29/01 
8;980782942;0;32;2;1  ;0;306;1  ;1  /29/01  3:42:22  PM;1  /29/01  %. 
8;980782942;0;32;2;1;0;306;1  ;1/29/01  3:42:22  PM  1/29/01  £1 


ICHM  1 " . ----- . ■  - 

Message. Type  8  I 

ANSI  Time:98078293b  ~  '  j 

T rue  Time  1  /29/01  3:42:1 0  PM ’ 

./«  _  .  .,v*~  meaaemmaatr :  •  ; 

Micro  Seconds  0  _  _ 

Location  ID  32  \ 


Machinery  ID  2^ 
Component  ID  1  ^ 
Request  ID  0^ 
t  Length  306 

.Number  to  Follow  1 


Figure  102  ICHM  Message  Header  Watcher 
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ICHM  Parameter  Data  Structure  Display 


A/OUT  RMS 


ARMS_HS.DE 
ARMS  HS  NDE 
ARMSlLS“DE 
ARMS_LS  NDE 
T_HS.DE 
T  HS  NDE 


1  0001 01 00/1.1 951 82E-Cq 
m  00010200;1.48674E-0r~ 
1  OOO103OO;1.279O8E-OS£j 


ANSI-Time  980781049  g^imeoRPay  1729701, 
Parameter  lD  0001 01 00  #^^lfco«fci3roiti430 
feli^Rg^aluejl  ■ 1 82033E-03  Low  Alarm  Level  435 
c&nP  isplayll  nits  Volts  'ftow  AierCLevel44Q 

Minimum  Value  16^579E?4§;:ry  :Hiqh  Limit  470 
Maximum  Value  30S.0982  High  Alariri  Levii;465 
Alarm  Wait  Time  0 _ _ I'HigK^jSrtSSvel ,460_ 


3:10:49  PM  _  M3mprtfslfeiiiridsl‘"0 
fe^iR^eiqhted-MaawST} 

F  EXP- Weighted  Variance,  0  “ 

_ _ ftSiiEXll^ecIw^teilO 

H  •'  l-^Rate  of  Change  •5.373QSSE-0 

Relative  R ate  of  Change'"'  0 
” ;  Bate  ofRate  of  Change^  &113871E-0I 


Figure  103  ICHM  Parameter  Structure  Display 
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15:14:48 
15:14:47 
15:14:46 
15:14:43 
15:14:41 
15:14:39 
15:14:36 
15:14:34 
15:14:32 
15:14:27 
15:14:25 
15:14:19 
15:14:17 
15:14:17 
15:14:17 
15:14:17 
15:14:16 
15:14:15 
15:14:12 
15:14:12 
15:14:12 
15:14:11 
15:14:11 
15:14:10 
'  15:14:09 
15:14:08 
15:14:08 
15:14:08 
15:14:08 


*  SendMessage:  Info  String:  I'mlCHMI 
-Alive for:  03:11:54 

-  Backing  up  ICHM1  working  ini  file 

-  SendMessage:  Process  String:  ichml  .aim 

•  SendMessage:  Info  String:  Alarm  file  is  ready 

-  RunMatlab  :gen!CHMFau!tFile  r:\ichm1.ini  r:\ichm1.alm 

-  RunMatlab  :proces$lniFaultData  r\ichm1.ini 

-  SendMessage:  Process  String,  ichml  .prm 
-SendMessage:  Info  String:  Parameter  file  is  ready.  Go  get  it 

-  RunMatlab  ;genlCHMParamFile  r:\ichm1.ini  r:\ichm1.prm 

-  RunMatlab : process! CHMR a wData  r:\intemp.dat  r:\ichm1.ini 

-  RunMatlab : process! CH MR awData  r:\electric8.dat  rAichm1.ini 

-  AcquireD  ata:  S  E  R  ate  N  umber  D  atal  D  FileN  ame 

-  AcquireD  ata:  1 4,1 4,1 000,1 000,2,intemp.  dat 

-  Digitizer  Card  Ready  (0) 

•  Initializing  Digitizer  Card 

-  Finished  collecting  dataO 

-  Started  collecting  data 

*  AcquireD  ata:  S  E  R  ate  N  umber  D  atal  D  FileN  ame 

•  AcquireD  ata:  0,7,20000,20000,1  ,electric8.  dat 

*  Digitizer  Card  Ready  (0) 

-  Initializing  Digitizer  Card 

-  Finished  collecting  dataO 

-  Started  collecting  data 

*  ReadCall  nfo:  CalibrationFilel  .txt 

•  Performing  ICHM1  INI  file  maintenance 
•ICHMID:  CID=1 

-ICHMID:  MID=2 
•ICHMID:  LID  =32 


J|  Closed  ij  Listening/lil  Resolving^  Cbnnecdrigy 
\  Zi  Close  Request  MOpen  Jfl  Resolved  M  Connected 

Pending  ERROR '• 


Figure  105  ICHM  Info  Display 


ICHM1 


IICHM2! 


ICHM  3 


ICHM  A 


1 2:1 2:03  -  AcquireD  ata:  S  E  Rate  Number  DatalD  FileN  ame 
1 2:1 2:02  -  AcquireD  ata:  0,3,20000,20000,3,accel.  dat 
1 2:1 2:02  -  Digitizer  Card  Ready  (0) 

12:12:02  -  Initializing  Digitizer  Card 

1 2:1 2:01  -  Finished  collecting  dataO 

12:11:51  -  SendMessage:  Process  String:  ichm2.alm 

12:11:59  -ReadCallnfo:  CalibrationFile2.txt 

12:12:00  *  Started  collecting  data 

12:11:59  -  Performing  ICHM2  INI  file  maintenance 

12:11:59 -ICHMID:  CID=2 

12:11:59 -ICHMID:  MID=2 


Hold  List 


Clear  List 


P^VoiceOn  fj.  RunMatlab 

T~  SendMessage  V  k  AcqureData 


fj  Alive 

r  jStart/Stop  Collection 


Figure  106  ICHM  Debug  Display 
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5. 1.4.5. 1.3  Results 

A  series  of  simulated  fault  conditions  (section  5, 1 .4.5. 1 . 1 )  were  tested  with  the  HMS 
installed  on  an  operating  501K17  SSGTG.  The  following  is  a  summary  of  processing, 
data  fusion,  classification  algorithm  and  messaging  modifications  that  were  made  based 
on  operation  of  and  data  collection  with  the  ICHMs  and  SHM  at  the  LBES.  Data 
collection,  processing  and  communication  operations  at  both  ICHM  and  SHM  functioned 
as  expected  with  no  problems  or  degradation  for  the  duration  of  the  LBES  test.  A  final  set 
of  fault  simulation  scenarios  were  conducted  as  part  of  the  LBES  demonstration/VIP  day. 

ICHM  1  (Generator  Electrical)  LBES  testing  did  not  indicate  any  required  changes  in  the 
processing,  data  fusion,  or  classification  algorithms  on  ICHM1. 

ICHM2  (Generator  Mechanical)  Data  from  LBES  testing  were  used  to  adjust  inputs  to 
the  feature  extraction  algorithms,  thresholds  used  in  the  data  fusion  and  pattern 
classification  algorithms,  and  alert  and  alarm  message  thresholds.  The  result  was  a 
significant  reduction  in  the  number  of  false  alert  and  alarm  messages  sent  to  the  SHM 
and  Watch  Station. 

ICHM3  (Reduction  Gearbox)  Data  from  LBES  testing  were  used  to  adjust  inputs  to  the 
feature  extraction  algorithms,  thresholds  used  in  the  data  fusion  and  pattern  classification 
algorithms,  and  alert  and  alarm  message  thresholds.  The  result  was  a  significant  reduction 
in  the  number  of  false  alert  and  alarm  messages  sent  to  the  SHM  and  Watch  Station. 
LBES  test  data  for  this  ICHM  and  ICHM4  also  showed  that  the  ICHM  internal 
temperatures  were  well  within  acceptable  operating  ranges  while  the  engine  was  running. 

ICHM4  (Accessory  Gearbox)  Data  from  LBES  testing  were  used  to  adjust  inputs  to  the 
feature  extraction  algorithms,  thresholds  used  in  the  data  fusion  and  pattern  classification 
algorithms,  and  alert  and  alarm  message  thresholds.  The  result  was  a  significant  reduction 
in  the  number  of  false  alert  and  alarm  messages  sent  to  the  SHM  and  Watch  Station. 
LBES  test  data  for  this  ICHM  and  ICHM3  also  showed  that  the  ICHM  internal 
temperatures  were  well  within  acceptable  operating  ranges  while  the  engine  was  running. 

SHM  LBES  testing  revealed  several  unresolved  message  format  problems  between  the 
SHM  and  the  ICHMs  and  between  the  SHM  and  the  Watchstation.  These  were  all 
resolved  satisfactorily  during  LBES  testing. 

Table  33  summarizes  the  three  classes  and  types  of  simulated  fault  testing  conducted 
during  the  final  LBES  demonstration/  VIP  day.  Table  33  is  representative  of  the  full  test 
matrix  described  in  section  5. 1.4.5. 1.1  above 
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5.1.4.5.2  Access  Point 
Fire: 

Due  to  the  limited  capabilities  of  LBES  facility,  the  fire  algorithm  has  been  stripped 
down  to  a  single  parameter,  temperature.  The  fire  algorithm  will  comprise  of  the 
temperature  sensors  from  multiple  sensor  clusters.  The  AP  will  monitor  the  sensor  cluster 
readings  for  high  level  or  rapid  changes.  Based  on  known  sensor  cluster  locations  the  AP 
will  determine  whether  or  not  an  alarm  will  be  issued.  2  adjacent  sensor  clusters  sensing  a 
high  temperature  will  be  viewed  as  an  alarm.  2  non-adjacent  clusters  detecting  a  high 
level  will  not  be  viewed  as  an  alarm. 

Results: 

The  location  discrimination  feature  of  the  algorithm  was  disabled  due  to  the  LBES/CG- 
61  physical  differences.  The  APs  shared  the  Sensor  Cluster  fire  data  across  the  individual 
APs  to  develop  a  compartment  wide  assessment  of  the  Sensor  Cluster  data.  The  Primary 
AP  then  issued  a  FIRE  alarm  to  the  watchstation. 

Flooding: 

The  flooding  algorithm  will  comprise  of  multiple  sensor  clusters  monitoring  the  water 
level  of  buckets  of  water.  The  AP  will  monitor  the  sensor  cluster  readings  for  high  level 
or  rapid  changes.  Based  on  known  sensor  cluster  locations  the  AP  will  determine 
whether  or  not  an  alarm  will  be  issued.  2  adjacent  sensor  clusters  sensing  a  high  water 
level  will  be  seen  as  an  alarm.  2  non-adjacent  clusters  detecting  a  high  level  will  not 
mean  an  alarm. 

Results: 

The  location  discrimination  feature  of  the  algorithm  was  disabled  due  to  the  LBES/CG- 
61  physical  differences.  The  APs  shared  the  Sensor  Cluster  flooding  data  across  the 
individual  APs  to  develop  a  compartment  wide  assessment  of  the  Sensor  Cluster  data. 
The  Primary  AP  then  issued  a  FLOOD  alarm  to  the  watchstation. 

High  Temperature: 

The  high  temperature  algorithm  is  design  to  minimize  the  number  of  false  alarms.  The 
algorithm  will  filter  the  temperature  readings  for  unacceptable  readings.  An  alarm  is 
issued  when  a  single  cluster’s  data  has  successfully  passed  the  filtering  process. 

Results: 

The  APs  shared  the  Sensor  Cluster  flooding  data  across  the  individual  APs  to  develop  a 
compartment  wide  assessment  of  the  Sensor  Cluster  data.  The  Primary  AP  then  issued  a 
HIGH  TEMPERATURE  alarm  to  the  watchstation. 

5.1.5  Fault  (loss  of  communications)  Recovery  Exercises 

Fault  recovery  exercises  are  design  to  flex  the  RSVP  architecture  and  its  associated 
system  components  and  to  illustrate  many  of  the  unique  features  of  the  RSVP  system. 
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The  following  sections  describe  the  various  recovery  schemes  inherent  in  the  RSVP 
architecture. 

5.1.5.1  APs 

5.1. 5.1.1  Loss  Of  Network  Communications  Between  AP  And  WS 

Action:  The  AP  will  issue  a  “kick-off”  command  to  all  connected  Sensor  Clusters. 

LBES  Results:  All  4  APs  issued  a  “kick-off”  command  to  the  APCM  units  causing  the 
Sensor  Cluster  to  migrate  to  other  APs. 

5.1. 5.1. 2  Loss  Communication  between  AP  to  APCM 

Action:  The  AP  will  issue  a  “kick-off”  command  to  all  connected  Sensor  Clusters. 

LBES  Results:  The  serial  line  connecting  the  AP  and  APCM  was  disconnected  and  the 
APCM  recognized  the  lose  of  communication  and  issued  a  “kick-off”  message  to  the 
Sensor  Clusters  forcing  them  to  migrate  to  other  APs. 

5.1 .5.2  Sensor  Clusters 

5.1. 5.2.1  Loss  of  Communications  between  Environmental  Sensor  Cluster  andAP 

Action:  If  the  Sensor  Cluster  fails  to  hear  a  down  link  message  from  the  AP  3  consecutive 
times  then  the  Sensor  Cluster  will  sequence  to  the  next  frequency  channel  in  its  AP 
frequency  table.  The  sensor  cluster  will  then  try  to  establish  communication  with  the  new 
AP. 

LBES  Results:  The  testing  consisted  of  shutting  down  APs  that  were  connected  to  Sensor 
Clusters.  The  Sensor  Clusters  would  then  migrate  to  an  operational  AP.  All  the  Sensor 
Clusters  operated  very  well  during  the  tests.  No  Sensor  Cluster  failed  to  switch. 

5.1. 5.2.2  Loss  Of  Communications  Between  SHM  To  AP 

Action:  If  communications  between  the  SHM  and  an  AP  fails,  then  the  SHM  will 
automatically  switch  to  another  AP  unit  in  that  given  compartment  and  try  to  establish 
communications. 

LBES  Results:  The  testing  consisted  of  shutting  down  APs  that  were  connected  to  the 
SHM.  The  SHM  would  sense  the  loss  of  communication  with  the  AP  and  then 
immediately  migrate  to  an  operational  AP. 

5.1. 5.2.3  Loss  of  Communications  between  SHM  to  ICHM 

Action:  If  communications  between  the  SHM  and  an  ICHM  fails,  then  the  SHM  after  a 
set  period  of  time  will  report  the  communications  loss  to  the  Watchstation  user  interface 
as  a  system  fault  in  the  alert/alarm  region  of  the  Data  screen.  Additionally,  loss  of 
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communication  between  the  AP  and  SHM  not  associated  with  a  problem  with  the  AP , 
would  result  in  an  SHM  communication  loss  message  at  the  Watchstation. 


LBES  Results:  Testing  consisted  of  powering  down  each  individual  ICHM  and  waiting 
for  the  system  alert  at  the  Watchstation.  Loss  of  ICHM  to  SHM  communication  alert 
messages  were  displayed  at  the  Watchstation  for  each  ICHM  when  it  was  turned  off. 
Loss  of  SHM  communications  was  tested  by  powering  down  the  SHM,  resulting  in  a 
system  alert  message  at  the  Watchstation 
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5.2  At-Sea  Demonstration 


5.2.1  Introduction 

The  purpose  of  the  At-Sea  demonstration  was  to  perform  an  evaluation  of  the  RSVP 
system  architecture  in  an  active  shipboard  environment  The  RSVP  system  was  installed 
aboard  the  USS  MONTEREY  (CG-61).  The  CG-61  conducted  a  number  of  at-sea 
exercises  while  the  RSVP  system  was  on  board  and  operational.  RSVP  team  members 
evaluated  the  system  while  CG-61  was  at-sea. 

The  RSVP  system  was  installed  in  the  Main  Engine  Room  #2  (MER#2).  The  RSVP 
system  consisted  of  the  RSVP  watchstation,  18  environmental  sensor  clusters,,  2 
structural  sensor  clusters,  5  PSM  units,  4  APs  and  1  HMS  (1  SHM  and  4  ICHMs). 
Overall  the  RSVP  system  was  installed  for  1 10  days.  Assessment  of  data  validity,  data 
accuracy,  and  optimum  system  configuration  was  not  performed  in  this  demonstration.  A 
number  of  scripted  scenarios  were  execute  to  simulate  conditions  that  can  not  be 
exercised  onboard  CG-61,  i.e.  fire  and  flooding.  All  four  functional  areas  were 
demonstrated  while  onboard  CG-61.  The  installation,  testing  and  removal  of  the  RSVP 
equipment  occurred  February  20  through  June  5,  2001.  Figure  107,  Figure  108,  Figure 
109  and  Figure  110  represent  the  locations  of  all  the  RSVP  equipment  in  MER#2.  The 
RSVP  watchstation  was  location  in  the  Central  Control  Station  (CCS). 

5.2.2  Equipment  Locations 


1st  Deck 


Figure  107  1st  Deck  of  MER#2 
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Figure  108  2nd  Deck  of  MER#2 


IMS  PWR  Supply  &  SHM  3rc(  [)eCJ< 


Figure  109  3rd  Deck  of  MER#2 


Figure  111  Typical  RSVP  Installed  Equipment  Suite 
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Figure  112  Typical  RSVP  HMS  Installation 


5.2.3  Test  Results 

Scenarios  for  each  of  the  monitoring  areas;  environmental  structural,  machinery  and 
personnel  are  described  in  detail  in  the  following  sections. 
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5.2.3. 1  Environmental  Sensor  Clusters 

5.2.3.1.1  Flooding  Scenario 

Fire  and  flood  detection  are  examples  of  the  scripted  scenarios.  Figure  1 13  is  plot  of 
actual  sensor  cluster  data  from  one  of  the  scenarios.  The  plot  highlights  many  of  the 
attributes  of  the  RSVP  architecture  including  adaptive  communication  rates  depending  on 
the  “environmental”  situation  and  the  “multt-  sensor  cluster”  decision  approach. 
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Figure  114  Watchstation  Navigation  Screen  -  Fire  Scenario 
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Figure  115  Watchstation  Information  Screen  —  Fire  Scenario 


5.2.3. 1.2  Fire  Scenario 

Similarly,  Figure  1 16  is  plot  of  actual  ensor  cluster  data  from  one  of  the  fire  scenarios. 
The  plot  highlights  again  the  many  of  the  attributes  of  the  RSYP  architecture  including 
adaptive  communication  rates  depending  on  the  “environmental”  situation  and  the 
“multi-sensor  cluster”  decision  approach.  The  fire  detection  algorithm  for  the  scripted 
scenario  was  set  at  trigger  on  multiple  high  temperature  sensor  cluster  alerts. 
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5.2.3.2  Structural  Sensor  Clusters 


Each  of  the  two  Structural  Sensor  Clusters  had  identical  sensor  suites.  The  suite  included 
2  UASTs  and  2  navigational  accelerometers  and  a  high-g  “shock”  accelerometer. 

Pictured  in  Figure  1 18  is  how  the  various  sensors  were  mounted  to  the  ship  structure.  One 
Structural  Sensor  Cluster  was  mounted  on  the  port  side  of  the  ship  and  the  other  was 
mounted  on  the  starboard  side  of  the  ship. 


Figure  118  The  Structural  Sensor  Cluster  Sensor  Suite  Mounting  Scheme 
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The  shock  monitoring  capability  of  the  RSVP  system  is  only  turned  “on”  when  General 
Quarters  is  announced  on  the  1MC.  Once  the  capability  is  turned  on  the  Sensor  Cluster  is 
monitoring  for  large  accelerations.  Figure  1 19  illustrates  actual  test  data  received  at  the 
APs  in  MER#2.  The  data  reveals  both  the  positive  and  negative  peaks  of  the  shock  but 
also  the  duration  of  those  peaks.  This  data  is  important  for  assessing  the  how  a  shock 
wave  may  have  propagated  through  the  ship  structure. 


Shock  Acceleration 
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The  RSVP  system  monitors  the  various  strain  levels  on  critical  beams  within  MER#2. 

The  UAST  strain  gauges  are  measuring  the  relate  stress  on  the  those  beams  and 
transmitting  that  data  to  the  APs  for  assessment  and  data  logging.  Pictured  in  Figure  120 
is  a  SARCOS  UAST  device  and  how  it  is  mounted  to  the  ship’s  structure.  The  device  was 
“zeroed”  pier  side  in  Norfolk,  YA. 


Figure  120  Sarcos  UAST  Strain  Sensor 


Illustrated  in  Figure  121  is  a  plot  of  actual  strain  measurements  taken  while  at-sea.  The 
measurements  represent  peak  values  of  strain  over  a  course  of  time.  Notice  the  occasional 
spikes  in  strain.  These  values,  depending  on  their  magnitude,  could  be  included  in  an 
automated  “cycle  counting”  system  that  monitors  fatigue  levels  over  the  life  of  the  ship. 
Shown  in  Figure  122  is  the  relative  magnitude  of  hull  strain.  NSWCCD  Structural 
engineers  have  verified  that  the  values  in  Figure  121  and  Figure  122  are  reasonable  given 
the  calm  seas. 
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Strain  Measurement 


Figure  121  At-Sea  Test  Data  For  Peak  Strain  Measurements 

Strain  Measurement 


Sansor  Raidings 


UAST  was  calibrated  to  “zero"  pier  side  on  the  MONTEREY  in  Norfolk 
Figure  122  Relative  values  of  hull  strain  measure  by  the  UAST  device 
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S.2.3,3  Machinery  Monitoring 


5. 2. 3. 3.1  Installation 

The  HMS  installation  on  the  USS  MONTEREY  CG61  consisted  four  ICHMs  and 
associated  sensors,  one  SHM,  a  generator  sensor  interface/instrament  power  interface  box 
and  a  power  supply.  The  HMS  System  was  self  contained  requiring  only  physical 
mounting  interfaces  for  hardware  and  sensor  and  1 10VAC  power  via  ships  power  and 
standard  power  receptacle.  The  HMS  hardware  arrangement  on  the  Allison  501K17 
SSGTG  is  repeated  in  Figure  123  for  clarity. 


Figure  123  HMS  Hardware  Arrangement 

ICHM  #1  monitoring  electrical  aspects  of  the  generator  and  ICHM  #2  monitoring 
mechanical  aspect  are  show  in  Figure  124,  Sensors  associated  with  electrical  and 
mechanical  monitoring  are  show  in  Figure  125  and  Figure  126  respectively. 
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/ 

USS  Monterey  CGbl  At  Sea  Demonstration 


Generator  Electrical  (1)  &  Mechanical  (2)  ICHMs  Installation 


Figure  124  Generator  Electrical  and  Mechanical  ICHM  Installation  Locations 
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Figure  126  Generator  Mechanical  Sensors  -  ICHM  #2 

ICHM  #3  monitoring  the  Reduction  Gear  Box  is  shown  in  Figure  127  along  with 
corresponding  sensors  in  Figure  128. 
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Figure  128  Reduction  Gear  Box  Sensors  -  ICHM  #3 


ICHM  #4  Monitoring  the  Accessory  Gear  Box  is  shown  in  Figure  129  and  corresponding 
sensors  are  show  in  Figure  130  and  Figure  131. _ 


Figure  129  Accessory  Gear  Box  ICHM  Installation  Location 
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Figure  131  Engine  Module  Temperature  -  ICHM  #4 
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5.2.3. 3.2  Machinery  Maintenance  Scenario 
5.2.3.3.2.1  Scenarios 

The  Machinery  Maintenance  Scenario  consists  of  four  discrete  conditions  designed  to  test 
the  detection,  assessment  and  notification  of  the  three  classes  of  faults  -  limit, 
component,  and  system.  HMS  equipment  required  for  the  each  test  included  the 
appropriate  ICHM,  the  SHM,  the  Watchstation  and  the  test  laptop  described  in  Section 
5. 1.4. 5. 1.2.  Condition  4  also  required  manipulation  of  all  four  ICHMs  and  SHM  using  the 
HMS  power  supply. 

Condition  1,  Limit  Fault  -  Reduction  Gear  Box  High  Vibration. 

Condition  2,  Component  Fault  -  Electrical  Generator  Winding  Fault.  -  60Hz  harmonics 
Condition  3,  System  Fault  -  Accessory  Gear  Box  Sensor(accelerometer)  Fault 
Condition  4,  System  Fault-  HMS  Loss  of  Communications  (ICHM  &  SHM) 


5.2.3.3.2.2  Pass/Fail  Criteria 

Pass/Fail  Criteria  consisted  of  successful  completion  of  each  step  described  in  Section 
5.2. 3. 3. 2.4.  Completion  of  these  steps  demonstrated  the  operation  and  functionality  of  the 
Machinery  Health  Monitoring  System  in  detecting  the  initiation  of  a  condition/fault, 
tracking  the  event/fault  evolution,  and  reporting/providing  information  to  an  operator  at 
the  RSVP  Watchstation  User  Interface.  A  summary  of  the  results  for  each  scenario  is 
contained  in  Table  34,  Table  35,  Table  36  and  Table  37. 


Table  34  Condition  #1  Bearing  Fault  Limit 


Machinery  HMS  -  Event  #1  Bearing  Fault  -  Limit 

Yes 

No 

1 .  HMS  collects/processes  accelerometer  data 

V 

2.  HMS  tracks  increasing  vibration  (trend) 

V 

.  HMS  detects  limit  exceedence,  sends  alert  message 

V 

4.  HMS  tracks  increasing  vibration  (trend) 

V 

5.  HMS  detects  limit  exceedence,  sends  alarm  message 

V 

6.  Upon  reset  to  normal  condition  -  HMS  detects  normal  condition  and 
sends  normal  message  to  WS  to  reset  alert/alarms 

V 

7.  Communication  maintained  with  AP/WS 

V 
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Table  35  Condition  #2  Electrical  Component  Fault 


Machinery  HMS  -  Event  #2  Electrical  Fault  -  Component 

Yes 

No  | 

1.  HMS  collects/processes  exciter  current  data 

V 

2.  HMS  tracks  changes  in  exciter  current  harmonics  (trend) 

V 

9H| 

3.  HMS  detects  limit  exceedence,  sends  alert  message 

V 

1 

4.  HMS  tracks  changes  in  exciter  current  harmonics  (trend) 

V 

I  1 

5.  HMS  detects  limit  exceedence,  sends  alarm  message 

V 

1 

6.  Upon  reset  to  normal  condition  -  HMS  detects  normal  condition  and 

V 

1 1 1 

sends  normal  message  to  WS  to  reset  alert/alarms 

BH 

7.  Communication  maintained  with  AP/WS 

V 

II 

Table  36  Condition  #3  System  Fault  -  Sensor 


Machinery  HMS  —  Condition  #3  Sensor  Failure  -  System 

Yes 

No 

1.  HMS  collects/processes  accelerometer  bias  voltage 

mm 

2.  HMS  detects  change  in  accel  bias  voltage 

mm 

3.  HMS  detects  system  fault,  sends  system  fault  message 

mm 

4.  HMS  detects  return  to  normal  bias  voltage 

mm 

5.  HMS  sends  normal  message  to  WS  to  reset  system  fault  (sensor) 
message 

m 

■ 

6.  Communication  maintained  with  AP/WS 

mm 

Table  37  Condition  #4  System  Fault  -  Communication  Failure 


Machinery  HMS  —  Event  #4  Communication  Failure  -  System 

Yes 

No 

ICHM  to  SHM  Communications 

1.  HMS  monitors  connections  between  ICHMs  and  SHM 

mm 

2.  SHM  detects  change  in  connectivity  with  ICHM 

mm 

3.  SHM  sends  system  communication  fault  message 

mm 

4.  HMS  detects  return  to  normal  ICHM/SHM  connectivity 

mm 

5.  HMS  sends  normal  message  to  WS  to  reset  system  notification 
(communication)  message 

m 

■ 

6.  Communication  maintained  with  AP/WS 

mm 

SHM  to  WS  Communications 

1 .  WS  monitors  connections  between  SHM  and  WS 

5S 

2.  WS  detects  change  in  connectivity  with  SHM 

■a 

3.  WS  displays  system  communication  fault  message 

Kfl 

4.  WS  detects  return  to  normal  SHM/WS  connectivity 

mm 

5.  WS  resets,  system  alert  message  changes  from  blue  to  gray 

wm 

6.  Communication  maintained  with  WS 

mm 
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5.2.3.3.2.3  Machinery  HMS  Test  Procedure 

The  objective  is  to  operationally  test  the  functionality  of  the  Machinery  Health 
Monitoring  System  and  display  of  information  at  the  Watchstation  in  context  of  the 
Machinery  Maintenance  Scenario  conditions. 

•  Initiation  and  Evolution  of  a  Bearing  Fault  -  vibration  limit  fault 

•  Initiation  and  Evolution  of  an  Electrical  Generator  Fault  -  electrical  component 
fault 

•  Sensor  Failure  -  system  fault 

•  HMS  (ICHM/SHM)  and  SHM  to  WS  Communication  Failures  -  system  fault 

During  each  condition  three  key  aspects  of  the  HMS  system  were  exercised  and  tested. 

•  detecting  the  initiation  of  an  event 

•  tracking  the  event  evolution 

•  reporting/providing  sufficient  information  about  the  event  to  an  operator  at  the 
RSVP  Watchstation  User  Interface. 


5.2.3.3.2.4  Test  Approach 

The  testing  approach  consisted  of  simulating  the  evolution  of  a  bearing  fault  in  the 
Reduction  Gearbox  and  an  electrical  fault  in  the  Generator  of  the  #2  SSGTG  located  in 
MER#2.  Simulation  was  accomplished  by  implementing  a  scripted  file  on  ICHM#3  and 
ICHM  #1  that  monitors  the  Reduction  Gearbox  and  Electrical  Generator  respectively. 

The  script  file  modified  data  as  it  was  collected  during  the  test,  to  illustrate  progression  of 
a  fault  condition.  Sensor  failures  were  accomplished  by  disconnecting  cables  to  the 
vertical  accelerometer  located  on  the  anti-drive  end  of  the  generator.  ICHM  to  SHM  and 
SHM  to  WS  communication  failures  were  initiated  by  powering  down  ICHM  #2  and 
SHM  respectively  at  the  HMS  power  supply. 

Conditions  land  2  are  described  in  two  ways.  First,  in  the  context  of  the  Health 
Monitoring  System  in  terms  of  time,  event,  anticipated  HMS  actions  (messages)  and 
Watchstation  actions/options.  (Table  38,  Table  40,  Table  42  and  Table  43).  Second,  each 
test  condition  is  described  in  the  context  of  the  simulation,  in  terms  of  time,  simulated 
action,  system  response,  and  anticipated  HMS/WS  action.  (Table  39  and  Table  41) 
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Expected  Result 

HMS  reports  overall  vibration 
level,  no  alert  or  alarm 
generated 

HMS  reports  overall  vibration 
level,  no  alert  or  alarm 
generated 

HMS  system  generates  alert 
message  on  RMS  vibration 
limit 

HMS  system  generates  alert 
message  on  RMS  vibration 
limit 

HMS  system  generates  alarm 
message  on  RMS  vibration 
limit 

HMS  system  generates  alarm 
message  on  RMS  vibration 
limit 

HMS  system  generates  alarm 
message  on  RMS  vibration 
limit 

HMS  system  reports 
alert/alarm  status  normal 

Description 

Vibration  signal  strength  increased  to 
simulate  onset  of  fault 

Vibration  signal  strength  increased  to 
simulate  growth  of  fault 

Vibration  signal  strength  increased  to 
level  exceeding  alert  limit 

Vibration  signal  strength  increased  to 
simulate  growth  of  fault 

Vibration  signal  strength  increased  to 
level  exceeding  alarm  limit 

Vibration  level  remains  steady  at  level 
exceeding  alarm  limit 

Vibration  level  remains  steady  at  level 
exceeding  alarm  limit 

Vibration  signal  strength  decreased  to 
within  normal  operating  limits 

Simulator 

Fault  simulator  1  amplifies 
raw  vibration  signal 

Fault  simulator  1  amplifies 
raw  vibration  signal 

Fault  simulator  1  amplifies 
raw  vibration  signal 

Fault  simulator  1  amplifies 
raw  vibration  signal 

Fault  simulator  1  amplifies 
raw  vibration  signal 

Fault  simulator  1  amplifies 
raw  vibration  signal 

Fault  simulator  1  amplifies 
raw  vibration  signal 
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5. 2. 3. 3. 3  Test  Results 


5.2.3.3.3.1  Condition  #1:  Vibration  Limit  Fault 


Condition  #1 :  Vibration  Limit  Fault 

Date  of  Test 

5/17/01 

Time  test  scenario  started: 

20:56 

Time  test  scenario  completed: 

21:04 

T-l  Peacetime  Steaming  -  Conditions  Normal 
Time  Started  20:56 
Time  complete  20:57 

Machinery  HMS 
ICHM  #2 

1 .  HMS  functioning  as  designed 

a.  Continuous  data  collection/processing 

b.  Vibration  Level 

c.  Temperature 

d.  Vibe/Temp  trend  data  available 

2.  HMS  tracks  vibration/temp  levels 

3.  Communications  with  SHM  maintained  during  test 
SHM 

1.  Communications  with  AP  maintained  during  test 


Y 

0.409g  RMS 
62.9 


Y 
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TO  Initiation  of  Bearing  F auit 

Time  Started  20:58 
Time  complete  20:59 

Machinery  HMS 
1CHM  #2 

1.  HMS  functioning  as  designed 

a.  Continuous  data  collection/processing 

b.  Vibration 

c.  Temperature 

d.  Vibe/Temp  trend  data  available 

2.  HMS  tracks  vibration/temp  levels 

3.  Communications  with  SHM  maintained  during  test 
SHM 

1 ,  Communications  with  AP  maintained  during  test 

T1  Bearing  Fault  Evolves 
Time  Started  20:59 

Time  complete  21:00 

Machinery  HMS 
ICHM  #2 

1.  HMS  functioning  as  designed 

a.  Continuous  data  collection/processing 

b.  Vibration 

c.  Temperature 

d.  Temp/Temp  trend  data  available 

2.  HMS  tracks  increase  in  vibration  level 

3.  Communications  with  SHM  maintained  during  test 
SHM 

1.  Communications  with  AP  maintained  during  test 

T2  Bearing  Fault  Identified  -  Alert  Limit 
Time  Started  21:00 

Time  complete  21:01 

Machinery  HMS 

1 .  HMS  functioning  as  designed 

a.  Continuous  data  collection/processing 

b.  Vibration 

c.  Temperature 

d.  Temp/Temp  trend  data  available 

2.  HMS  tracks  increase  in  vibration  level 

3.  Vibration  exceeds  limit,  ICHM  generates  alert 

4.  Alert  displayed  at  WS 

5.  Alert  explanation/details  provided 

6.  Communications  with  SHM  maintained  during  test 
SHM 

1,  Communications  with  AP  maintained  during  test 


Y 

0.400g  RMS 
62.8  F 

Y 

Y 

Y 

Y 


Y 

0.579g  RMS 
62.9  F 

Y 

Y 

Y 

Y 


Y 

22.3g  RMS 
62.9  F 

Y 

Y 

Y 

Y 

Y 

Y 

Y 
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T3  Bearing  Fault  Evolves 
Time  Started  21:01 

Time  complete  21:02 

Machinery  HMS 

1 .  HMS  functioning  as  designed 

a.  Continuous  data  collection/processing  Y 

b.  Vibration  24.5g  RMS 

c.  Temperature  62.9  F 

d.  Temp/Temp  trend  data  available  Y 

2.  HMS  tracks  increase  in  vibration  level  Y 

3.  ICHM  continues  to  generates  vibe  limit  alert  Y 

4.  Alert  displayed  at  WS  Y 

5.  Alert  explanation/ details  provided  Y 

6.  Communications  with  SHM  maintained  during  test  Y 

SHM 

1 .  Communications  with  AP  maintained  during  test  Y 


T4  Bearing  Condition  Exceeds  Limits  for  Mission  Profile 


Time  Started  21:02 
Time  complete  21:03 

Machinery  HMS 

1 .  HMS  functioning  as  designed 

a.  Continuous  data  collection/processing  Y 

b.  Vibration  60.3g  RMS 

c.  Temperature  62.9  F 

d.  Temp/Temp  trend  data  available  Y 

2.  HMS  tracks  increase  in  vibration  level  Y 

3.  Vibration  exceeds  limit,  ICHM  generates  alarm  Y 

4.  Alarm  displayed  at  WS  Y 

5.  Alarm  explanation/details  provided  Y 

6.  Communications  with  SHM  maintained  during  test  Y 

SHM 

1 .  Communications  with  AP  maintained  during  test  Y 


T5  and  T6  Repair  Action  Taken  and  Completed  -  Not  Applicable  to  RSVP  System 
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T7  Bearing  Condition  Normal 
Time  Started  21:03 
Time  complete  21:04 

Machinery  HMS 

1 .  HMS  functioning  as  designed 

a.  Continuous  data  collection/processing  Y 

a.  Vibration  5.4g  rms 

b.  Temperature  62.9  F 

c.  Temp/Temp  trend  data  available  Y 

2.  HMS  tracks  vibration  level  Y 

3.  Vibration  within  normal  limits  Y 

4.  Vibration  level  5  4g  rms 

5.  Alert/Alarms  cleared/reset  at  WS  Y 

6.  Communications  with  SHM  maintained  during  test  Y 

SHM 

1.  Communications  with  AP  maintained  during  test  Y 
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5.2.3.3J.2  Condition  #2:  Electrical  Component  Fault 


Condition  #2:  Electrical  Component  Fault 

Date  of  Test 

5/17/01 

Time  test  scenario  started: 

21:05 

Time  test  scenario  completed: 

21:16 

T-l  Peacetime  Steaming  -  Conditions  Normal 
Time  Started  21:05 
Time  complete  21:06 

Machinery  HMS 
ICHM  #1 

1 .  HMS  functioning  as  designed 


a. 

Continuous  data  collection/processing 

Y 

b. 

Current 

3390 

A 

c. 

Voltage 

466 

V 

d. 

Exciter  Current 

20.3 

A 

e. 

f 

Exciter  Voltage 

Trend  data  available 

28.8 

V 

2.  HMS  tracks  electrical  parameter  levels 

3.  Communications  with  SHM  maintained  during  test 
SHM 

1 .  Communications  with  AP  maintained  during  test 

TO  Electrical  Component  Fault  Initiation 
Time  Started  21:06 

Time  complete  21:08 

Machinery  HMS 
ICHM  #1 

1 .  HMS  functioning  as  designed 


a. 

b. 

Continuous  data  collection/processing 

Current 

3390 

c. 

Voltage 

466 

d. 

Exciter  Current 

20.3 

e. 

Exciter  Voltage 

28.8 

f  Parameter  levels  within  normal  limits 
g.  Trend  data  available 

2.  HMS  tracks  electrical  parameter  levels 

3.  Communications  with  SHM  maintained  during  test 
SHM 

1 .  Communications  with  AP  maintained  during  test  Y 
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T1  Electrical  Problem  Evolves 
Time  Started  21:08 

Time  complete  21:09 

Machinery  HMS 
ICHMM 

1.  HMS  functioning  as  designed 


a. 

b. 

Continuous  data  collection/processing 

Current 

3390 

a 

Voltage 

466 

d. 

Exciter  Current 

20.3 

e. 

Exciter  Voltage 

28.8 

f.  Parameter  values  within  normal  limits 

g.  Trend  data  available 

2.  HMS  tracks  electrical  parameter  levels 

3.  Communications  with  SHM  maintained  during  test 
SHM 

1.  Communications  with  AP  maintained  during  test 


Y 

Y 

Y 

Y 

Y 


T2  Component  Fault  Identified 
Time  Started  21:09 
Time  complete  21:10 

Machinery  HMS 
ICHMM 


1.  HMS  functioning  as  designed 


a.  Continuous  data  collection/processing 

Y 

b.  Current 

3390 

A 

c.  Voltage 

466 

V 

d.  Exciter  Current 

20.3 

A 

e.  Exciter  Voltage 

28.8 

V 

f  Parameter  values  within  normal  limits 

Y 

g.  Trend  data  available 

Y 

2.  HMS  identifies  electrical  components  fault 

Y 

3.  ICHM  generates  alert  message 

Y 

4.  Alert  displayed  at  WS 

Y 

5.  Alert  explanation/details  provided 

Y 

6.  Communications  with  SHM  maintained  during  test 

Y 

SHM 

1.  Communications  with  AP  maintained  during  test 

Y 
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T3  Electrical  Component  Fault  Evolves 
Time  Started  21:10 
Time  complete  21:11 

Machinery  HMS 
ICHMU1 

1 .  HMS  functioning  as  designed 


a. 

b. 

Continuous  data  collection/processing 

Current 

3390 

c. 

Voltage 

466 

d. 

Exciter  Current 

20.3 

e. 

Exciter  Voltage 

28.8 

f  Parameter  values  within  normal  limits 
g.  Trend  data  available 
3. 1CHM  continues  to  generate  alert  message 

4.  Alert  displayed  at  WS 

5.  Alert  explanation/details  provided 

6.  Communications  with  SHM  maintained  during  test 
SHM 

1 .  Communications  with  AP  maintained  during  test 

T4  Electrical  Component  Condition  Exceeds  Limits  for  Mission  Profile 
Time  Started  21:11 

Time  complete  21:13 

Machinery  HMS 
ICHM  #1 

1 .  HMS  functioning  as  designed 


a. 

b. 

Continuous  data  collection/processing 

Current 

3390 

c. 

Voltage 

466 

d. 

Exciter  Current 

20.3 

e. 

Exciter  Voltage 

28.8 

f.  Parameter  values  within  normal  limits 

g.  Trend  data  available 

3.  Electrical  component  condition  deteriorates,  ICHM  generates  alarm 

4.  Alarm  displayed  at  WS 

5.  Alarm  explanation/details  provided 

6.  Communications  with  SHM  maintained  during  test 
SHM 

1 .  Communications  with  AP  maintained  during  test  Y 

T5  and  T6  Repair  Action  Taken  and  Completed  -  Not  Applicable  to  RSVP  System 
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17  Electrical  Component  Condition  Normal 
Time  Started  21:15 
Time  complete  21:16 

Machinery  HMS 
ICHM  #1 

1 .  HMS  functioning  as  designed 

a.  Continuous  data  collection/processing 


b.  Current  3 3 90 

c.  Voltage  466 

d.  Exciter  Current  20.3 

e.  Exciter  Voltage  28.8 


f  Parameter  values  within  normal  limits 
g.  Trend  data  available 

2.  Electrical  component  returned  to  normal  condition,  ICHM  generates  *: 
alarm  message 

3.  Alarm  is  cleared/reset  at  WS 

4.  Communications  with  SHM  maintained  during  test 
SHM 

1 .  Communications  with  AP  maintained  during  test  Y 
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5.2.3.3.3.3  Condition  3:  Sensor  Fault 


Condition  3:  Sensor  Fault 

Date  of  Test 

5/17/01 

Time  test  scenario  started: 

21:17 

Time  test  scenario  completed: 

21:22 

T-l  Peacetime  Steaming  -  Conditions  Normal 
Time  Started  21:17 
Time  complete  21:20 

Machinery  HMS 
ICHM  #2 

1 .  HMS  functioning  as  designed 

a.  Continuous  data  collection/processing  Y 

b.  Vibration  Level  .057g  RMS 

c.  Temperature  66.6 

d.  Temp/Volt  trend  data  available 

2.  HMS  tracks  vibration/temp/bias  voltage  levels 

3.  Communications  with  SHM  maintained  during  test 
SHM 

1.  Communications  with  AP  maintained  during  test 


TO  Initiation  of  Sensor  Fault 
Time  Started  21:20 

Time  complete  21:21 

Machinery  HMS 
ICHM  #2 

1 .  HMS  functioning  as  designed 

a.  Continuous  data  collection/processing 

b.  Vibration  .057g 

c.  Temperature  66.6 

d.  Temp/Volt  trend  data  available 

5.  HMS  tracks  vibration/temp  levels 

6.  HMS  detects  system  problem  -  sensor  bias  volt  exceeded 

7.  HMS  generates  system  alert  message 

8.  Alert  displayed  at  WS 

9.  Alert  explanation/details  provided 

10.  Communications  with  SHM  maintained  during  test 
SHM 

1.  Communications  with  AP  maintained  during  test  Y 
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T2  Sensor  Fault  Repaired 
Time  Started  21:21 
Time  complete  21:22 

Machinery  HMS 
ICHM  #2 

1 .  HMS  functioning  as  designed 

a.  Continuous  data  eolleetion/processing  Y 

b.  Vibration  0.057g  RMS 

c.  Temperature  58.3  F 

d.  Temp/Volt  trend  data  available  Y 

2.  HMS  tracks  vibration/temp/sensor  bias  voltage  levels  Y 

3.  HMS  detects  normal  sensor  condition  Y 

4.  HMS  generates  ‘normal’  system  alert  message  Y 

5.  System  Alert  message  cleared/reset  at  WS  Y 

6.  Communications  with  SHM  maintained  during  test  Y 

SHM 

1.  Communications  with  AP  maintained  during  test  Y 
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5.2.3.3.3.4  Condition  4:  Communication  Fault 


Condition  4:  Communication  Fault 

Date  of  Test 

5/17/01 

Time  test  scenario  started: 

21:22 

Time  test  scenario  completed: 

21:31 

T-l  Peacetime  Steaming  -  Conditions  Normal 
Time  Started  21:22 

Time  complete  21:28 

Machinery  HMS 
ICHM  #2 

1 .  HMS  functioning  as  designed 

a.  Continuous  data  collection/processing 

b.  Vibration  Level 

c.  Temperature 

d.  Temp/Vibe  trend  data  available 

2.  HMS  tracks  vibration/temp  level 

3.  Communications  with  SHM  maintained  during  test 
SHM 

1.  Communications  with  AP  maintained  during  test 

TO  Initiation  of  Communication  Fault 
Time  Started  21:28 

Time  complete  21:29 

Machinery  HMS 
ICHM  #2 

1.  HMS  functioning  as  designed 

a.  Continuous  data  collection/processing 

b.  Vibration  Level 

c.  Temperature 

d.  Temp/Vibe  trend  data  available 

2.  HMS  tracks  vibration/temp/sensor  bias  voltage  levels 
SHM 

1.  Loss  of  communication  with  ICHM  detected  (pwr  dwn) 

2.  SHM  generates  system  alert  message 

3.  System  alert  message  displayed  at  WS 

4.  Alert  explanation/details  provided 


Y 

0.057g  RMS 
64.3 


0.057g 

64.3 


Y 


270 


NSWCCD-TR-2003/02 


T1  Communication  Fault  Repaired 
Time  Started  21:29 
Time  complete  21:31 

Machinery  HMS 
SHM 

1 .  Communication  restored  w/  ICHM  detected  (pwr  up)  Y 

2.  SHM  generates  ‘normal’  system  alert  message  Y 

3.  System  alert  message  cleared/reset  at  WS  Y 

ICHM  #2 

1 .  HMS  functioning  as  designed  Y 

a.  Continuous  data  collection/processing  Y 

b.  Vibration  0.01 6g  RMS 

c.  Temperature  66.0  F 

d.  Temp/Vibe  trend  data  available  Y 

2.  HMS  tracks  vibration/temp/sensor  bias  voltage  levels  Y 


5.2.3.3.4  HMS  Operation 

The  SSGTG  Health  Monitoring  System  operated  continuously  for  the  duration  of  the 
installation  aboard  the  CG  61  USS  MONTEREY  from  March  7, 2001  through  June  4, 
2001.  During  that  time  the  ICHMs  collected  and  analyzed  130  GB  of  data  and  archived 
roughly  26  GB  of  data  from  42997  snap  shots.  During  this  time,  the  SSGTG  #2  was 
operational  30days  out  of  91  days,  approximately  33%of  the  time. 

Consistent  with  the  trouble-free  operation  of  the  SSGTG,  no  problems  were  detected  by 
the  Health  Monitoring  System.  Additionally,  the  HMS  generated  no  false  alerts  or 
alarms.  Although  uneventful  in  terms  of  fault  detection,  several  important  capabilities  of 
the  HMS  were  demonstrated.  The  SSGTG  Health  Monitoring  System  automatically, 
without  user  intervention,  collected  and  conducted  detailed  data  analysis  regarding  the 
health  of  the  SSGTG  for  the  duration  of  the  installation.  Information  about  the  health  and 
operation  of  the  SSGTG  was  presented  at  the  Watchstation  based  on  an  event  or  request 
basis.  An  operator  was  presented  with  important  information,  alerts,  alarms  and/or  data  as 
warranted  as  well  as  access  data/information  down  to  the  sensor  level  was  available  at 
any  time. 

Operation  of  the  HMS  during  the  at  sea  demonstration  phase  also  confirmed  applicability 
of  data  collection  and  analysis  techniques  in  the  operational  environment.  Of  concern  was 
the  signal  to  noise  ratio  (SNR)  while  the  ship  was  underway  and  the  impact  of  multiple 
noise  sources.  Comparisons  of  background  noise  spectra  on  the  SSGTG  while  in  port  and 
underway  with  the  turbine  off  indicated  that  the  low  frequency  vibration  of  the  ship  did 
not  affect  the  data,  Figure  133.  Comparisons  of  spectra  from  LBES  and  the  ship 
underway  with  the  turbine  on,  indicated  very  similar  signal  to  noise  ratio  and  the 
presence  of  spectral  tones  of  interest,  Figure  134  and  Figure  135.  This  was  important  for 
two  reasons.  First,  it  showed  that  sensors  could  be  installed  on  the  SSGTG  that  would 
collect  quality  data  and  support  health  monitoring  analysis  while  in  the  operational 
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environment.  Second,  it  proved  that  the  data  analysis  techniques  and  algorithms 
developed  in  the  laboratory  and  tested  on  the  SSGTG  at  LBES  could  be  expected  to 
perform  as  well  on  board  ship. 


K17  Turbine  Off  -  at  Port  vs.  Underway 


K1 7  T urbine  Off  -  at  Port  vs.  Underway 


Figure  133  Comparison  of  Background  Noise  In-Port  and  Underway  -  SSGTG  Off 


FreqHz  FreqHz 

Figure  134  Comparison  of  Generator  Vibration  Underway  and  at  LBES -SSGTG  On 
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^  Underway  Reduction  Gearbox  Ch:1 


4q  . i . 4  .....4 »f. 

*33  — . .  4 . 1  -  -4 . 1- . 5  4  - 


mm  sccc  mm  mn  mn  mm  ram  ?m  tot 

FreqHz 


LIES  Reduction  Gearbox  Chi 


•4a 


•60  ••••; . i . . . ; . *  -•  ...j  ;  .. 

-ggi — i - i - 1 - i - i - i - 1 - 1 - i — 

am  am  sot  s«n  ssm  um  tod  rm  ?4W 

FreqHz 


Figure  135  Comparison  of  RGB  Spectra  Underway  and  at  LBES  -  SSGTG  On 


S.2.3.4  Personnel  Monitoring 

Four  PSM  units  (ISU  and  CIU)  were  used  in  the  At-Sea  demonstration.  RSVP  test  team 
member  wore  the  PSM  units  for  the  various  evaluation  exercises.  The  PSM  system  has 
various  built-in  self  diagnostics  to  signal  when  for  instance  the  system  is  not  being  worn 
properly.  The  plot  of  PSM  data  shown  in  Figure  136  identifies  a  situation  of  the  ISU 
electrode  that  determine  the  wearer’s  heart  rate  is  not  making  proper  contact.  An  error 
code  is  generated  and  sent  to  the  APs  for  notification. 

Figure  136  represents  PSM  messages  received  at  the  APs  within  MER#2,  The  data 
contained  in  the  messages  supports  the  assessment  of  the  wear’s  overall  physiological 
state  contained  in  the  individual  messages.  The  overall  physiological  status  for  this 
particular  data  is  2  or  a  yellow/caution  condition  -  Figure  137.  After  examining  the 
supporting  data  you  notice  the  electrode  flag  is  set  indicating  that  ISU  belt  electrode  is 
not  making  proper  contact.  The  PSM  system  continues  to  monitor  the  remaining 
parameters  and  determines  that  there  is  no  need  to  issue  an  ALARM  condition  because 
the  wearer  is  in  acceptable  ranges  for  the  other  body  parameters. 
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PSM  Data  (G.  Schwartz) 


"  Skin  Temp 
Pulse 


PSM  S/N#  2  -  K.  Toomey  -  Indication 


AP  4002  524/01  13  29  39.202  PST  2  OREMT  0  Motion  0  PANIC  0  ELE  1  SHIVER  0  PULSE  89  ATemp  34.1 

A P  4002  5/24/01  13  29  54202  PST  2  ORIENT  0  Motion  0  PANIC  0  ELE  1  SHIVER  0  PULSE  88  ATemp  34.1 

AP  4002  524/01  13  30  9295  PST  2  ORIENT  0  Motion  0  PANIC  0  BE  1  SHIVER  0  PULSE  94  ATemp  34.1 

I  AP  4002  5/24401  13  30  24.307  PST  2  ORIENT  0  Motion  0  PANIC  0  BE  1  SHIVER  0  PULSE  95  ATemp  34.1  | 

AP  4002  5/24/01  13  30  39.308  PST  2  ORENT  0  Motion  0  PANIC  0  B£  1  SHIVER  0  PULSE  95  ATemp  34.1 

AP  4002  5/24/91  13  30  54.31  PST  2  ORIENT  0  Motion  0  PANIC  0  ELE  1  SHIVER  0  PllSE  98  ATemp  34.1 

AP  4002  5/24/01  13  31  9.301  PST  2  ORIENT  0  Motion  0  PANIC  0  ELE  1  SHIVER  0  PULSE  94  ATemp  34.1 

AP  4002  5/24/91  13  31  24.202  PST  2  ORIENT  0  Motion  0  PANIC  0  ELE  1  SHIVER  0  PULSE  84  ATemp  34.1 

Message  received  on  AP2 

Time  =  13:30:24.307 

PSM  Status  =  2:  Yellow 

Orientation  =  0:  Vertical 

Rapid  Motion  =  0:  Not  moving 

Panic  =  0:  No  panic 

Electrode  =  1:  Not  making  contact 

Shiver  =  0:  Not  Shivering 

Pulse  =  95:  95  bpm 

Atemp  =  34.1:  skin  temp  of  34.1  °C 

Messages  received,  processed  and  stored  at  the  RSVP  Access  Point 

Figure  137  PSM  Yellow  Indication 
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Figure  138  represents  again  more  PSM  messages  received  at  the  APs  within  MER#2.  The 
overall  physiological  status  for  this  particular  data  is  3  or  a  red/alarm  condition.  After 
examining  the  supporting  data  you  notice  the  panic  flag  is  set  indicating  that  wearer  has 
pressed  the  panic  button  on  the  CIU  box.  The  PSM  system  continues  to  send  a  alarm 
condition  until  the  CIU  box  power  is  cycled  or  the  batteries  run  out  of  energy. 


PSM  S/N#  4  -  G.  Schwartz  -  RED  Indication 
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12:54:44.522  Panic  button  pressed 
12:54:52.567  PSM  issues  an  alarm 

Why  the  8  second  delay?  The  PSM  physiological  status  algorithm 

is  executed  every  15  seconds.  The  button 
was  pressed  in  the  middle  of  the  sleep  period. 

Figure  138  PSM  Red  Indication 


5.2.3.S  Personnel  Tracking 

The  ability  to  determine  a  sailor’s  location  within  the  ship  has  been  identified  as  a  desired 
feature  especially  in  a  minimally  manned  ship.  The  majority  of  the  compartments  are 
small  enough  that  just  knowing  the  a  sailor  is  in  a  given  compartment  is  sufficient 
enough.  However  in  larger  compartment  such  as  MER#2  you’d  like  to  know  more  detail 
as  to  the  location  of  the  sailor.  Figure  139  represents  the  output  of  a  compartment  level 
algorithm  that  is  trying  to  determine  the  location  of  a  sailor  within  MER#2.  The  data  that 
was  used  to  generate  the  plot  was  gathered  during  the  YIP  demonstration  held  on  May  24 
onboard  the  USS  MONTEREY.  The  wearer  was  assigned  the  duty  of  escorting  the  VIPs 
from  the  one  demonstration  station  to  another  demonstration  station  that  was  located  in 
MER#2.  For  the  most  part  the  wearer  was  standing  near  API  (noted  4001  in  the  plot)  but 
when  the  demonstration  was  completed  the  escort  navigated  through  the  compartment  to 
the  next  station  and  then  returned  to  the  original  API  station.  The  “navigation”  period  of 
time  is  captured  in  the  plot  by  the  APs  #2  and  #3  having  the  greater  signal  strength. 
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Personnel  Tracking 

PSM#2  (M.  Donnelly) 
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Figure  139  Location  Determination  Within  MER#2 


One  of  the  key  attributes  that  the  RSVP  team  wanted  to  capture  during  the  US  S 
MONTEREY  demonstration  was  the  overall  performance  of  the  low-power  RF  network 
architecture.  Included  in  the  AP  as  part  of  the  data  logging  feature  is  the  ability  to 
determine  the  bit  error  rate  (BER)  of  a  particular  sensor  cluster  unit.  Figure  140  is  a 
screen  capture  of  sensor  cluster  data  messages  received  at  the  AP  during  one  of  the  at-sea 
tests.  What  the  data  is  telling  us  is  that  for  sensor  cluster  s/n  1 1 1  a  BER  of  2%  is  being 
realized.  The  RSVP  BER  is  1%  so  a  2%  BER  is  very  close  and  acceptable. 
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Bit  Error  Rate  (BER) 


Paul  Bunyan  Message  Viewer  -  Untitled  -  [What  a  Long  Strange  Tup  It's  Been] 


5/26/01  4:27:49  PM 
5728/01  4:27:43  PM 
5/26/01  4:27:44  PM 
5/26/01  4:27:23  PM 
5/26/01  4:27:26  PM 
5/26/01  4:27:14  PM 
5/26/01  4:26:59  PM 
5/26/01  4:26:46  PM 
5/26/01  4:26:44  PM 
5/26/01  4:26:31  PM 


HT1  56  HT2  56,  HT3  56  02  vat  cf 
Diagnostic  Data  for  Sensor  number :  0x10313331 
EnvDataFusion  qReading$:0,  qSeraorsO,  qFireO,  qFIoodO,  qTemp;0 
EnvDataFusion  qReatfings:0,  qSen$or$:0,  qFireQ,  qFIoodO,  qT  emp:0 

SendSMDataQ  Failed  CRC  SN  0x10313131  mType  32  nDataMsg  80532  nErr  2124  ttE/HM  0.026375 
EnvDataFusion  qReadings:0,  qSensors:0,  qFireO,  qFIoodO,  ql  emp:0 
EnvDataFusion  qReadings:0,  qSemorsrO,  qFneO,  qFIoodO,  qTemp:0 

SendSMDataQ  Failed  CRC  SN  0x10313131  rnType  32  nDataMsg  80516  nErr  2123  8E/8M  0.026367 
EnvDataFusion  qReadIngs:0,  q$ensors:0,  qFireO,  qFIoodO,  qTemp:0 
EnvDataFusion  qReading$:2,  qSensors:2,  qFireO,  qFIoodO,  qTemp:0 


mlwa  32  nDataMsg  80532  nErr  21 24  HE 


Environmental 
Sensor  Cluster 
S/N:  111 


Standard  data 
uplink  message 


2%  BER  for 
this  AP. 
Goal:  1% 


Figure  140  Bit  Error  Rate  (BER) 
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5.2.3.6  Power  Harvesting 

5.2.3.6.1  Power  Management  Module  (PMM) 


The  PMM  was  connected  with  Sensor  Cluster  #02  of  Figure  141.  A  Photovoltaic  Array 
and  the  Thermo-Electric  Energy  Harvesting  Generator  (Figure  142)  were  connected  to 
the  PMM  and  supplied  harvested  power  to  the  sensor  cluster  as  battery  augmentation. 


Figure  141  Sensor  Cluster  with  PIMM  and  Diagnostic  Board 


Figure  142  Thermo-Electric  Harvesting  Generator  and  Photovoltaic  Array 
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5.23.6.2  Photovoltaic  Input 

If  the  photovoltaic  array  were  placed  directly  under  a  lighting  fixture,  it  could  produce 
the  required  amount  of  power;  however,  if  it  were  placed  above  the  fixture  where  the  top 
is  typically  totally  shielded,  then  it  would  produce  no  power.  Power  from  the 
Photovoltaic  array  was  not  measured  during  this  evaluation  because  it  was  determined 
during  risk  mitigation  testing  that  there  would  be  no  measurable  current  in  the  ambient 
lighting  conditions  from  this  particular  array.  The  array  was  connected  to  demonstrate  the 
interface.  A  more  efficient  array,  and  one  that  would  have  been  cost  prohibitive  for 
RSVP,  could  be  acquired  to  power  the  PMM, 


5.23.63  Vibration-to-Electric  Input 

The  technology  developed  for  RSVP  vibrational  power  harvesting  is  too  immature  and 
undeveloped  to  be  a  viable  power  source  even  under  the  most  favorable  conditions  at  this 
time.  However,  it  may  become  a  viable  power  source  in  the  future.  The  Vibration-to- 
Electric  power  harvesting  device  was  not  connected  to  the  cluster  because  an  interface  to 
the  PMM  board  was  not  developed.  The  Vibration-to-Electric  power  harvesting  device 
was  brought  to  the  CG-61  for  display. 

5.23.6.4  Thermo-Electric  Input 


Tests  were  ran  in  controlled  conditions  at  35, 20,  10  and  5  degrees  delta  T  with  loads  of 
open,  1M,  500K,  200K,  150K  and  100K.  Measurement  stopped  when  the  voltage 
dropped  below  3.3  volts  because  it  is  unusable  at  that  point. 

35  Degrees  Delta  T  :  Cold=9QF  Hot=l25F 


open 

5.3  volts 

.000  raA 

1M 

4.65 

.004 

500K 

3.96 

.007 

200K 

3.35 

.016 

150K 

3.15 

.020 

20  Degrees 

Delta  T  :  Cold=90F  Hot=1 1 0F 

open 

5.13  volts 

.000  mA 

1M 

4.50 

.004 

500K 

3. BO 

.007 

200K 

2.78 

.013 
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10  Degrees  Delta  T  :  Cold=90F  Hot=100F 


open  5.03  volts 

1M  4.26 

500K  3.52 
200K  2.3 


.006 


.000  mA 
.004 

.011 


5  Degrees  Delta  T  Cold=95F  Hot=100F 

open  4.85  volts  .000  mA 

1M  4.14  .004 

500K  3.40  .006 

200K  2.18  .010 

As  the  results  indicate,  the  Thermo-Electric  generator  did  not  develop  enough  current  in 
any  of  the  tests  to  power  the  cluster. 


S.2.3.6.5  Summary 

The  PMM  was  designed  to  handle  lma  at  3.3  volts  average  power  with  lOOma  at  3.3 
volts  peak  demand.  How  much  power  that  could  have  been  drawn  from  the  power 
harvesting  devices  is  very  dependent  upon  the  specific  location  in  the  environment  in 
which  they  are  placed.  Inappropriate  placement  could  yield  no  power  at  all.  This 
evaluation  revealed  that  power  harvesting  was  most  technologically  immature  of  the 
RSVP  components.  There  are  no  COTS  products  currently  available  and  cost  effective 
that  meet  RSVP  design  goals.  More  development  is  required  to  provide  the  anticipated 
power  loads  for  wireless  sensors  in  these  areas.  RSVP  expects  commercial  development 
to  continue,  and  expects  maturation  of  these  technologies. 
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5.3  Ex-US S  Shadwell 

5.3.1  Introduction 

The  objective  for  the  R8VP  ex-USS  SHADWELL  Demonstration  is  to  exercise  and 
demonstrate  environmental  and  personnel  monitoring  capabilities  in  an  integrated 
environment.  The  R3VR  ex-USS  SHADWELL  demonstration  will  be  a  collaborative 
effort  between  the  Damage  Control  -  Automation  for  Reduced  Manning  (DC -ARM) 
program  and  the  RSVP  program.  RSVP  sailor  status  and  location  information  will  be 
exchanged  via  the  SHADWELL  LAN  to  the  two  supervisory  control  systems  being 
demonstrated  during  the  September  FY01  demonstrations. 

The  following  is  a  sample  of  RSVP  performance  requirements  that  were  established  at 
the  beginning  of  the  program  by  a  number  of  government  and  industry  experts.  A 
complete  listing  can  be  found  in  the  RSVP  Systems  Engineering  Study. 

•  RSVP  will  alert  an  operator  that  there  is  a  fire  in  a  compartment. 

•  Goal  for  probability  of  missed  detection:  0.2%  of  actual  fires. 

•  Goal  for  time  to  detection  of  a  Class  A  fire  (due  to  combustibles  on  the  ship,  not 
an  external  event):  5  min. 

•  Goal  for  probability  of  false  alarm:  2/year  per  ship  1  (approximately  500 
compartments). 

•  RSVP  will  alert  an  operator  that  there  is  an  incipient  fire  in  a  compartment. 

•  Goal  for  alert  time  prior  to  ignition:  5  min.  An  alert  will  be  given  prior  to 
ignition? 

•  RSVP  will  alert  an  operator  that  a  crew  member  is  undergoing  extreme  fatigue. 

•  RSVP  will  allow  an  operator  to  continuously  track  the  location  (to  the 
compartment  level)  of  crew  members  over  the  range  of  motion  from  stationary  to 
running. 

•  RSVP  will  allow  an  operator  to  track  crew  members’  vital  signs  with  a  maximum 
latency  of  0.5  minute. 

Prior  to  the  FY01  demonstration,  workup  tests  were  conducted  on  board  the  ex-USS 
SHADWELL.  The  workup  tests  reflected  the  fire  and  flood  scenarios  that  were  executed 
during  the  formal  test  phase  of  the  demonstrations.  The  workup  tests  were  executed 
during  the  same  time  period  as  the  DC -ARM  workup  tests  and  in  many  cases  were  the 
same  test  scenario  identified  in  the  DC-ARM  FY01  Test  Plan.  Workup  tests  were  held 
between  August  1  through  August  31, 2001.  The  purpose  of  the  work-ups  was  to  refine 
the  fire  scenarios  and  to  exercise  the  supervisory  control  systems.  The  FY01  Peacetime 
Demonstrations  were  held  during  September  10  through  14  and  the  FY01  Wartime 
Demonstrations  were  held  during  September  24  through  28,  2001.  The  RSVP  remained 
onboard  the  SHADWELL  because  of  ONR  desire  to  have  a  second  VIP  demonstration 
onboard  SHADWELL  in  February  2002. 
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5.3.2  Equipment  Locations 

The  RSVP  team  provided  72  environmental  sensor  clusters,  1  structural  sensor  cluster 
and  10  PSM  units  and  the  RSVP  watchstation.  The  HMS  was  installed  on  the 
SHAD WELL’s  fire  pump  #2  but  was  not  part  of  the  formal  testing.  Depicted  in  Figure 
143,  Figure  144,  and  Figure  145  are  the  locations  of  the  RSVP  equipment  onboard 
SHAD  WELL. 


Main  Deck  of  ex-USS  5HADWELL 


Cobling- 


Power 

Source 


Access  Point  (AP) 

Access  Point  Comm.  Module  (APCM) 
Environmental 


Sensor  Cluster  Unit 
—  Ethernet  (CAT5) 


0  hub 


Compartment  Numbers  Correspond  with  AP  Numbers 


Figure  143  Main  deck  RSVP  equipment  locations 
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2nd  Deck  of  ex-USS  SHA DWELL 
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As  mentioned  previously  the  SHAD  WELL  demonstration  was  broken  into  two  phases, 
peacetime  and  wartime  scenarios. 

5.3.3  Peacetime  Scenarios 

The  RSVP  peacetime  scenarios  were  a  subset  of  the  DC -ARM  peacetime  scenarios 
because  the  RSVP  system  was  not  installed  in  all  of  the  compartments  the  DC -ARM 
equipment  was  installed  in.  For  RSVP  the  peacetime  scenarios  included  a  computer 
monitor  fire,  a  diesel  engine  exhaust,  a  smoldering  electrical  cables,  a  bedding  fire  and 
the  grinding  of  metal.  Over  the  next  few  pages  the  results  from  the  various  peacetime 
scenarios  will  be  discussed. 

Figure  146  and  Figure  147  represent  the  test  configuration  and  test  results  for  the 
computer  monitor  fire.  The  location  of  all  the  RSVP  equipment  is  identified  as  well  as  the 
location  of  the  source.  The  observations  that  were  made  are  included  the  table.  Specific 
sensor  cluster  fire  detection  indexes  are  plotted  also  to  illustrate  what  the  sensor  cluster 
“saw”  during  the  test. 


Computer  Monitor  w/  Cal  Rod 


Test 

Activity 

Time 

RSVP 

Information 

Ignition 

12:50 

Fjre  Announced; 
Rapid  Response 
Team  dispatched 

12:54:19 

Alert  SC140 

12:55:14 

Alarm  SC140  &  SC142 

Fire  Extinguished 
by  Rapid  Response 
Team 

12:56 

12:56:05 

Alarm  SC140,  SC141 
&  SC142 

Figure  146  Computer  Monitoring  Fire  Test  Setup 
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Computer  Monitor  w/  Cal  Rod 


> 


Session  Number 


Figure  147  Sensor  Cluster  #140  Fire  Detection  Indexes 


During  the  test  the  voltage  to  the  cal  rod  had  to  be  increased  due  to  the  minimal  effect  the 
lower  voltage  had  at  starting  the  fire.  Because  of  his  the  detection  time  was  rather  long 
but  still  within  the  5  minute  detection  requirement. 

Figure  148  and  Figure  149  represent  the  test  configuration  and  test  results  for  the  diesel 
engine  exhaust  scenario.  The  location  of  all  the  RSVP  equipment  is  identified  as  well  as 
the  location  of  the  source.  The  observations  that  were  made  are  included  the  table. 
Specific  sensor  cluster  fire  detection  indexes  are  plotted  also  to  illustrate  what  the  sensor 
cluster  “saw”  during  the  test. 
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Diesel  Engine  Exhaust 


Activit 


Initiate 


Terminate 


RSVP 

Information 


12:54:20 

TBD 

12:57:28 

Alert  SC172 

12:58:33 

Alarm  SC166  &  SC172 

TBD 

Figure  148  Diesel  Engine  Exhaust  Test  Setup 


Diesel  Engine  Exhaust 


-  DV(Aggregate) 
DV(Heptane) 

-  DV(Rags) 

"  DV (Smoke) 

-  DV(Wood) 
“Threshold 


Engine  Stopped 
13:23:00 

\ 

r 

Alert  Issued 
12:57:28 


Engine  Starte 
12:50:50 
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Figure  149  Sensor  Cluster  #172  Fire  Detection  Indexes 


After  seven  minutes  of  ran  time  the  compartment  was  fully  engulfed  with  a  light  smoke 
from  the  generator,  which  is  what  lead  the  sensor  cluster  alert  condition.  Even  tough  the 
there  was  no  actual  fire  the  detection  algorithm  did  detected  a  dangerous  condition  and 
notified  the  watchstander. 

Figure  150  and  Figure  151  represent  the  test  configuration  and  test  results  for  the 
smoldering  electrical  cable  scenario.  The  location  of  all  the  RSVP  equipment  is  identified 
as  well  as  the  location  of  the  source.  The  observations  that  were  made  are  included  the 
table.  Specific  sensor  cluster  fire  detection  indexes  are  plotted  to  illustrate  what  the 
sensor  cluster  “saw”  during  the  test. 


Smoldering  Electrical  Cable 


Time 

RSVP 

Information 

Cal  rod  set  to  50  V 

13:55 

Cal  rod  set  to  60  V 

14:05 

Visible  smoke 

14:17 

14:20:43 

Alert  SC178 

Fire  reported 

14:32:45 

Extinguished 

14:34:30 

Figure  150  Smoldering  Electrical  Cable  Test  Setup 
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Smoldering  Electrical  Cable 


Session  Number 


Figure  151  Sensor  Cluster  #178  Fire  Detection  Indexes 

Similar  to  the  computer  monitor  fire  test,  the  cal  rod  was  set  a  low  voltage,  which 
basically  heated  up  the  cable.  The  cal  rod  voltage  was  increased  which  resulted  in  smoke 
coming  from  the  cable  bundle,  within  3  minute  the  sensor  cluster  issued  an  alert  which  is 
within  the  RSVP  requirement  of  5  minutes. 

Figure  152  and  Figure  153  represent  the  test  configuration  and  test  results  for  the  bedding 
fire.  The  location  of  all  the  RSVP  equipment  is  identified  as  well  as  the  location  of  the 
source.  The  observations  that  were  made  are  included  the  table.  Specific  sensor  cluster 
fire  detection  indexes  are  plotted  to  illustrate  what  the  sensor  cluster  “saw”  during  the 
test. 
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Within  21  seconds  a  sensor  cluster  issued  an  alert  condition  and  within  110  seconds  three 
sensor  clusters  issued  alerts.  All  of  which  was  within  the  RSVP  requirement  of  5  minutes. 

Figure  154  and  Figure  155  represent  the  test  configuration  and  test  results  for  the 
grinding  of  metal  scenario.  The  location  of  all  the  RSVP  equipment  is  identified  as  well 
as  the  locatbn  of  the  source.  The  observations  that  were  made  are  included  the  table. 
Specific  sensor  cluster  fire  detection  indexes  are  plotted  to  illustrate  what  the  sensor 
cluster  “saw”  during  the  test. 


Grinding 


Test 

Activity 

Time 

RSVP 

Information 

Initiate 

13:03 

13:06 

Alert  SC  169 

13:08:43 

Alarm  SC169  &  SC172 

13:10 

Another  Alarm  SC167 

Terminate 

13:11 

Figure  154  Grinding  Test  Setup 
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Figure  155  Sensor  Cluster  #169  Fire  Detection  Indexes 

The  grinding  of  metal  was  most  difficult  situation  to  discriminate  against.  After  close  to  4 
minutes  of  grinding  on  metal  the  compartment  environmental  conditions  were  very  cbse 
to  the  conditions  that  seen  by  a  real  fire.  The  significant  amount  of  sparks  and  smoke 
made  the  grinding  resembled  a  bedding  of  wood  type  of  fire. 
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5.3.4  Wartime  Scenarios 

RSVP  will  leveraged  the  wartime  fire  scenarios  identified  in  Section  4.3  of  the  DC-ARM 
FY01  Test  Plan.  RSVP  will  monitor  a  subset  of  the  fire  fighting  team(s)  for  physiological 
adversity  and  location  within  the  port  and  starboard  passageways  between  frames  15  and 
29  on  the  main  and  second  decks.  Even  though  the  RSVP  equipment  is  not  high 
temperature  tolerant  a  certain  subset  of  the  RSVP  equipment  were  located  in  some  of 
compartments  during  the  wartime  scenarios.  The  compartments  had  “adjacent  to  primary 
damage  area”  type  fires  where  the  temperature  would  be  less  likely  to  reach  65°C,  the 
threshold  for  the  water  mist  system.  Steps  were  taken  to  mitigate  the  impact  of  the  water 
mist  system  if  it  were  to  be  activated  in  these  specific  compartments. 

Figure  156  describes  the  layout  of  the  Tomahawk  Equipment  room.  Identified  are  the 
locations  of  the  RSVP  equipment  and  the  source  location.  The  situation  that  will  be 
discussed  now  was  part  of  the  VIP  demonstration  scenario  that  was  held  on  September 
26,  2001.  Similar  result  exist  for  the  other  similar  RSVP  compartments. 


Tomahawk  Equipment  Room 


RSVP  Equipment  Locations 


|  Access  Point  Communication  Module 
#  Environmental  Sensor  Cluster 


Figure  156  Tomahawk  Equipment  Room  Layout 

Figure  157  represents  the  messages  being  sent  to  the  RSVP  watchstation.  The  messages 
are  being  generated  based  on  the  output  of  the  compartment- level  fire  detection 
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algorithm.  As  you  can  see  the  duration  of  the  situation  and  whose  contributing  to  the 

detection  of  the  situation  is  being  sent  to  the  watchstation. 

_ Tomahawk  Equipment  Room  Messages _ 

09/26  13:26:45.928  Comp:  3  Inst:  30000  Type:  2  bur:  1:22  M in  Fire  alarm  106  108  109 
09/26  13:26:50.620  Comp;13  Inst;13Q000  Type:  2  Dur:  11:14  Min  Fire  alarm  162  170  171 172 
09/26  13:26:55.810  Comp:ll  Inst:110000  Type:  1  bur:  0.0  Sec  Fire  alert  125 
09/26  13:27:01.443  Comp:12  Inst:120000  Type:  1  bur:  0.0  Sec  Fire  alert  176 
09/26  13:27:05.622  Comp:13  Inst:130000  Type:  2  bur:  11:29  Min  Fire  alarm  162  170  171 172 
09/26  13:27:09.872  Comp:  3  Inst;  30000  Type:  2  bur;  1:46  Min  Fire  alarm  106  108  109 
09/26  13:27:10.812  Comp:  11  Inst:  110000  Type:  1  bur:  16.0  Sec  Fire  alert  125 
09/26  13:27:16.443  Comp:12  Inst:120000  Type:  2  bur:  15.0  Sec  Fire  alarm  174  176  178 
09/26  13:27:20.622  Comp:13  Inst:130000  Type:  2  bur;  11:44  Min  Fire  alarm  162  170 171 172 
09/26  13:27:24.874  Comp:  3  Inst:  30000  Type:  2  bur:  2:01  Min  Fire  alarm  106  108  109 
09/26  13:27:30.811  Comp:  11  Inst: 110000  Type:  2  bur:  36.0  Sec  Fire  alarm  124  125 
09/26  13:27:36.443  Comp:12  Inst:120000  Type:  2  bur:  35.0  Sec  Fire  alarm  174  175  176  178 
09/26  13:27:39.876  Comp:  3  Inst;  30000  Type;  2  bur:  2:16  Min  Fire  alarm  106  108  109 
09/26  13:27:40.622  Comp:13  Inst:130Q00  Type:  2  bur:  12:04  Min  Fire  alarm  162  170  171 172 
09/26  13:27:45.812  Comp:ll  Inst;110000  Type:  2  bur:  51.0  Sec  Fire  alarm  124  125 
09/26  13:27:54.878  Comp:  3  Inst:  30000  Type:  2  bur:  2:31  Min  Fire  alarm  106  108  109 


Note:  All  messages  being  published  from  there  respective  compartments. 

Figure  157  Compartment -Level  Messages  Being  Sent  To  The  RSVP  Watchstation 

Specific  sensor  cluster  fire  detection  indexes  for  Sensor  Cluster  #176  can  be  found  in 
Figure  158.  The  plot  illustrates  what  the  sensor  cluster  “saw”  during  the  test. 


Sensor  Cluster  Fire  Detection  Models 
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Figure  158  Sensor  Cluster  S/N  #176  Fire  Detection  Indexes 

Figure  159  illustrates  the  evolution  of  the  fire  that  took  place  in  the  Tomahawk 
Equipment  room. 

Sensor  Cluster  Fire  Detection  Models 


Figure  159  Fire  Evolution  Illustration 
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5.3.4.1  Personnel  -  Physiological  Status 


Sailor  Status 
Flow  Chart 


Figure  160  PSM’s  physiological  Status  Algorithm 
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PSM  RED  Alarm 


SN  0x40000004  AP  4012  COMP  c  12  28  27.5  CST  0  1ST  0 

SN  0x40000004  AP  4012  COMP  c  12  28  39.8  CST  0  1ST  0 

SN  0x40000004  AP  4012  COMP  c  12  28  47.4  CST  0  1ST  0 

SN  0x40000004  AP  4012  COMP  c  12  28  48.4  CST  0  1ST  0 

SN  0x40000004  AP  4012  COMP  c  12  28  54.8  CST  0  1ST  0 

SN  0x40000004  AP  4012  COMP  c  12  28  54.8  CST  0  1ST  0 

SN  0x40000004  AP  4012  COMP  c  12  28  54.8  CST  0  1ST  0 

SN  0x40000004  AP  4012  COMP  c  12  32  29.5  CST  0  1ST  0 

t  i 

CIU  Panic  button 

- pressed  resulting 

in  a  REb  alarm 


PST  3 
PST  3 
PST  3 
PST  3 
PST  3 
PST  3 
PST  3 
PST  3 


ORIENT  0 
ORIENT  0 
ORIENT  0 
ORIENT  0 
ORIENT  0 
ORIENT  0 
ORIENT  0 
!  ORIENT  0 


Motion  1 
Motion  0 
Motion  0 
Motion  0 
Motion  0 
Motion  0 
Motion  0 
Motion  0 


PANIC  1 
PANIC  1 
PANIC  1 
PANIC  1 
PANIC  1 
PANIC  1 
PANIC  1 
PANIC  1 


ELE  0 
ELE  0 
ELE  0 
ELE  0 
ELE  0 
ELE  0 
ELE  0 
ELE  0 


SHIVER 

SHIVER 

SHIVER 

SHIVER 

SHIVER 

SHIVER 

SHIVER 

SHIVER 


0  PULSE  162 
0  PULSE  80 
0  PULSE  80 
PULSE  80 
PULSE  84 
PULSE  84 
PULSE  84 
PULSE  90 


ATemp  46 
ATemp  30 
ATemp  30 
ATemp  30 
ATemp  35 
ATemp  35 
ATemp  35 
ATemp  31 


Figure  161  PSM  Red  Alarm 


PSM  YELLOW  Alert 


SN  0x40000002  AP  4009  COMP  9  14  5  27.2  CST  0  1ST  0 

SN  0x40000002  AP  4009  COMP  9  14  5  42.2  CST  0  1ST  0 

SN  0x40000002  AP  4009  COMP  9  14  5  57.2  CST  0  1ST  0 

SN  0x40000002  AP  4009  COMP  9  14  6  27.2  CST  0  1ST  0 

SN  0x40000002  AP  4009  COMP  9  14  6  42.2  CST  0  1ST  0 

SN  0x40000002  AP  4009  COMP  9  14  14  27.2  CST  0  1ST  0 

SN  0x40000002  AP  4009  COMP  9  14  14  42.2  CST  0  1ST  0 

SN  0x40000002  AP  4009  COMP  9  14  14  57.2  CST  0  1ST  0 

SN  0x40000002  AP  4009  COMP  9  14  21  27.2  CST  0  1ST  0 


Improper  ISU 
electrode  contact 
resulting  in  a  YELLOW  alert 


PST  2 

ORIENT 

0 

Motion 

0 

PANIC 

0 

ELE 

1 

SHIVER 

0 

PULSE 

210 

ATemp  34 

PST  2 

ORIENT 

0 

Motion 

0 

PANIC 

0 

ELE 

1 

SHIVER 

0 

PULSE 

210 

ATemp  34 

PST  2 

ORIENT 

0 

Motion 

0 

PANIC 

0 

ELE 

1 

SHIVER 

0 

PULSE 

210 

ATemp  34 

PST  2 

ORIENT 

0 

Motion 

0 

PANIC 

0 

ELE 

1 

SHIVER 

0 

PULSE 

210 

ATemp  34 

PST  2 

ORIENT 

0 

Motion 

0 

PANIC 

0 

ELE 

1 

SHIVER 

0 

PULSE 

210 

ATemp  34 

PST  2 

ORIENT 

0 

Motion 

0 

PANIC 

0 

ELE 

1 

SHIVER 

0 

PULSE 

210 

ATemp  35 

PST  2 

ORIENT 

0 

Motion 

0 

PANIC 

0 

ELE 

1 

SHIVER 

0 

PULSE 

210 

ATemp  36 

PST  2 

ORIENT 

0 

Motion 

0 

PANIC 

0 

ELE 

1 

SHIVER 

0 

PULSE 

210 

ATemp  36 

PST  2 

ORIENT 

0 

Motion 

0 

PANIC 

0 

ELE 

1 

SHIVER 

0 

PULSE 

210 

ATemp  36 

Figure  162  PSM  Yellow  Alert 


296 


NSWCCD-TR-2003/02 


S.3.4,2  Personnel  -  Location  Determination 

As  in  the  MONTEREY  demonstration  the  ability  to  determine  a  sailor’s  location  within 
the  ship  has  been  identified  as  a  desired  feature  especially  in  a  minimally  manned  ship. 
For  SHAD  WELL  we  are  interest  in  tracking  the  sailor  has  he  moves  from  compartment 
to  compartment  in  the  RS  VP  test  area.  Over  the  next  few  pages  the  results  of  the  location 
determination  algorithm  will  be  presented.  It  should  be  noted  that  a  ship  survey  was 
required  to  calibrate  the  algorithm  so  that  the  algorithm  could  discriminate  from  one 
compartment  from  the  adjacent  compartment. 


Location  Determination  on  the  Main  Deck 


Location  Determination  Algorithm  at  Wotchstatlon 
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Figure  163  Results  Of  Sailor  Tracking  On  The  Main  Deck 


297 


«>Cornpartment 

=>Compartment 

=>Compartment 

»>Compartment 

=>Compartment 

=>Compartment 

»>Conpartment 

=>Cocnpartment 

=>Conpartment 

=>Compartment 

«>Conpartment 

;=>Compartment 

=>Conpartment 

=>Compartment 

:=>Cocnparttnent 

‘«>Canpartment 

.=>Compartment 

^Compartment 

'=»>Compartrrent 


5  (SN:2,  G 
5  (SN : 2,  G 
10  (SN:2, 
10  ( SN : 2 , 

10  (SN:2, 

11  (SN:2, 
11  (SN:2, 

10  (SN:2, 

11  (SN :  2 , 
10  (SN:2 , 

10  (SN:2, 

11  (SN : 2 , 
11  (SN:2, 
11  (SN:2, 
10  (SN :  2 , 
10  ( SN :  2  , 

10  (SN: 2 , 

11  (SN:2, 
11  (SN :  2 , 


RSS1 : 96) 
RSSI ;  96} 

,  RSSI: 97)  ** 
,  RSSI: 92) 

,  RSSI: 100) 

,  RSSI: 150) 

,  RSSI : 151) 

,  RSSI: 72) 

,  RSSI: 150) 

,  RSSI : 93) 

,  RSSI: 91) 

,  RSSI :151) 

,  RSSI: 151) 

,  RSSI: 151) 

,  RSSI: 105)  " 
,  RSSI: 105) 

,  RSSI: 105) 
r  RSSI: 150) 

,  RSSI: 150) 


Compartment  6  was  not  picked  up. 
*  Possibly: 

-  Sailor  moving  quickly 

-  Blocked  CUI  communication 

-  AP/APCM  not  working 


Panic  button  pressed  and  then  reset 


298 


NSWCCD-TR- 2003/02 


Figure  165  Graphic  of  sailor  tracking  on  the  2nd  Deck 


Location  Determination  on  the  3rd  Deck 


Location  Determination  Algorithm  at  Watchstation 


==>Compartment : 13 

(SN; 2, 

Green  t 

RSSI : 84) 

==>Compartment ; 23 

(SN;2, 

Green  , 

RSSI : 98) 

==>Compartment : 13 

(SN ;  2 

Green  , 

RSSI: 100} 

== >Compartment ; 13 

( SN ; 2 , 

Green  # 

RSSI: 95) 

==>Compartment :  13 

(SN;2, 

Green  , 

RSSI; 99} 

==>Compartinent:  13 

(SN :  2  f 

Green  , 

RSSI; 99} 

==>Compartment : 13 

(SN; 2 , 

Green  , 

RSSI : 99} 

==>Compartment ; 12 

{ SN ; 2 , 

Green  , 

RSSI: 93) 

=->Compartment : 12 

(SN ; 2 1 

Green  ( 

RSSI; 82} 

==>Compartment ; 12 

(SN : 2 , 

Green  , 

RSSI : 82} 

==>Compartment ; 13 

{ SN ; 2 , 

Green  f 

RSSI; 102} 

==> Compartment : 13 

(SN; 2 , 

Green  , 

RSSI: 102} 

==>Compartment ; 13 

( SN ; 2 , 

Green  , 

RSSI : 0) ^ 

Test  Summary 


PSM  Test 

9/14/01 

loute 

lomp 

Time 

Deck 

l 

’ll 

57:10 

Main 

l 

11 

57:50 

Main 

% 

11 

58:35 

Main 

9 

11 

59:45 

2nd 

3 

12 

00:20 

2nd 

7 

12 

02:00 

2nd 

3 

???????? 

2nd 

3 

12 

03  ;  08 

2nd 

L  1 

12 

03:50 

2nd 

L  0 

12 

05:45 

2nd 

L  1 

12 

06:36 

2nd 

12 

07  :  15 

3rd 

.2 

12 

08  :  03 

3rd 

.3 

12 

08:46  • 

3rd 

Sxi  t 

12 

09:30 

3rd 

Left  Compartment  #13  | 


Figure  166  Results  Of  Sailor  Tracking  On  The  3rd  Deck 
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5.3.4.3  Flood  Detection 

The  flood  detection  algorithm  was  demonstrated  in  starboard  passageway  on  the  2  deck, 
Sensor  Cluster  #156’s  pipette  was  used  to  measure  the  water  depth.  The  flooding  was  a 
result  of  a  simulated  pipe  burst.  The  flooding  alert  threshold  was  set  to  1”  of  water.  Due 
to  the  fact  I  only  one  pipette  was  used  in  the  test  the  RSVP  system  is  only  going  to  issue 
an  alert  condition,  had  a  second  pipette  been  used  then  an  ALARM  conditions  would 
have  been  issued  once  both  reading  were  over  the  1”  level.  The  results  from  the  flooding 
scenario  are  shown  in  Figure  167. 


2nd  beck  -  Starboard  Passageway 

(Sensor  Cluster  #156  Flooding  Monitoring) 


Figure  167  Sensor  Cluster  #156  Flooding  Data 
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6.0  Additional  Results 

6.1  Manning  Analysis 

6.1.1  Manning  Reductions 

RSVP  tasked  Carlow,  Ine  to  conduct  a  third  phase  of  the  Manning  Analysis  for  RSVP. 
The  objective  of  the  effort  was  to  address  workload/manpower  reduction  issues,  and 
apply  Human  Systems  Integration  (HSI)  methods  to  assess  usability  of  the  RSVP 
operator  interface. 

In  a  previous  Carlow  report,  “RSVP  Manning  Functional  Analysis  Study  (MFAS)”[ref 
3],  baseline  workload  data  for  engineering  control  watchstanders  under  Condition  III 
steaming  and  for  damage  control  personnel  during  a  fire  and  flood  scenario  were  used  to 
estimate  workload  reduction  due  to  introduction  of  RSVP.  In  both  cases,  previous 
analyses  of  workload  associated  with  the  existing  designs  were  reviewed  and  work  load 
redistributed  according  to  the  functionality  of  RSVP  and  its  ability  to  perform  extensive 
ship  monitoring,  data  analysis  and  fusion.  The  results  included  estimated  workload 
reductions  of: 

•  73%  for  the  Damage  Control  Administrator/DC  team  located  in  Damage  Control 
Central  for  a  fire  and  flood  scenario  aboard  the  DDG-51 

•  47%  for  personnel  tasks  performed  in  the  machinery  spaces  aboard  DDG-51  for 
each  four-hour  watch  under  condition  III  steaming. 

A  considerable  portion  of  the  engineering  control  workload  reduction  noted  above  was 
due  to  assumed  elimination  of  the  need  for  roving  equipment  monitors  to  manually 
record  machinery  and  environmental  parameters  during  hourly  or  semi- hourly  rounds  in 
the  engineering  spaces.  The  capability  of  RSVP  to  automate  this  data  collection  effort 
was  investigated. 

The  estimated  workload/manpower  reduction  potential  of  RSVP  assumed  that  much  of 
the  data  recording  workload  currently  performed  by  roving  monitors  in  the  machinery 
spaces  could  be  eliminated  using  RSVP  sensors,  data  collection  and  archiving.  Roving 
monitors  currently  read  local  displays  of  machinery  and  environmental  parameters  and 
record  these  observations  on  standard  data  sheets  during  rounds  in  the  engineering 
spaces.  The  issue  was  investigated  of  the  engineering  complexity  involved  in  these 
observations  and  measurements. 
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In  connection  with  RSVP  usability  testing  aboard  the  USS  MONTEREY  (CG-61),  copies 
of  data  collection  sheets  were  obtained  that  were  used  by  the  roving  monitors  to  record 
machinery  parameters  during  rounds  in  the  engineering  spaces.  The  parameters  recorded 
by  roving  monitors  are  listed  in  Appendix  A.  These  were  classified  as  follows: 

•  Visual  observation  of  fluid  level  or  condition  using  a  sight  glass 

•  Moisture 

•  Fluid  level 

•  Discrete  mode  (e.g.  ID  of  the  pump  currently  on  line  where  more  than  on  is 
available) 

•  Air  flow 

•  Time  (e.g.  cumulative  run  time  for  a  component) 

•  Electrical  current 

•  Pressure 

•  Temperature 

Figure  168  shows  the  cumulative  frequencies  of  the  parameter  types  in  ascending  order 
of  the  estimated  complexity  of  automatically  measuring  the  parameter  via  sensors.  Most 
of  the  parameter  types  present  no  problem  and,  in  fact,  are  cirrently  measured  by  the 
prototype  RSVP  system.  Fluid  level  measurements  in  general  are  somewhat  more 
complicated  than  are  temperature,  pressure,  etc.  Moisture  determination  would  require 
assessment  of  water  content.  Measurements  that  currently  use  human  observation  of  a 
sight  glass  would  require  analysis  of  the  exact  target  property.  Such  observations  often 
involve  fluid  level  or  fluid  quality  (e.g.  contaminants  in  fuel  or  lubricating  oil)  and  might 
be  obtained  by  level  or  chemical  analysis. 
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Figure  168  Roving  Monitor  Parameters 
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Figure  168  indicates  the  cumulative  percent  of  all  parameters  that  could  be 
accommodated  if  the  type  in  question  and  all  less  complex  types  could  be  measured. 
Measurements  of  temperature  alone  would  accommodate  about  35  percent  of  all 
parameters.  Measurements  of  temperature  and  pressure  would  accommodate  about  67 
percent  of  all  parameters.  Measurements  of  parameters  up  and  including  fluid  level 
would  accommodate  over  90  percent  of  all  parameters  and  would  very  nearly  obviate  the 
need  for  hourly  rounds  by  roving  monitors.  For  complete  results,  refer  to  the  “RSVP 
Manning  Functional  Analysis  Phase  III  Report”  [ref  15]. 

6.1.1.1  Usability  Testing 

Usability  testing  was  conducted  during  the  RSVP  land-based  and  at  at-sea 
demonstrations  and  test  programs.  Ship  personnel  who  were  familiar  with  engineering 
control  activities  used  the  RSVP  watch  station  to  step  through  the  graphic  user  interface 
(GUI)  and  their  comments  were  recorded.  Walkthroughs/talkthroughs  were  conducted 
for  the  screens  that  were  applicable  to  tasks  and  user  comments,  questions  and  issues 
were  recorded.  During  the  at-sea  test,  two  participants  commented  on  the  screens.  The 
test  participants  were  Navy  personnel  who  were  familiar  with  engineering  control 
activities. 

User  computer  interface  issues  and  recommendations  were  developed  using  the  test 
participant  comments  and  reviews  of  the  screens  by  Carlow  project  personnel  applying 
UCI  design  guidelines  from  the  HSI  and  human  factors  literature.  For  the  RSVP 
demonstrations  and  tests,  the  watehstation  presented  a  stand  alone  RSVP  GUI.  This  will 
probably  not  be  the  mode  of  implementation  used  when  RSVP  technology  is  integrated 
aboard  future  ships.  The  prototype  RSVP  GUI  used  for  this  project  did  not  contain 
provisions  for  machinery  control  since  RSVP  was  conceived  and  designed  to  fill  a  health 
monitoring  function  -  not  to  support  machinery  control.  Nevertheless,  the  GUI  approach 

to  navigation  to  screens  associated  with  compartments,  machines,  etc.  was  considered  to 
be  quite  effective. 

An  ideal  engineering  control  or  damage  control  workstation  might  include: 

•  The  navigation  facilities  of  RSVP  as  a  top  layer 

*  A  second  machinery  control  layer  with  screens  similar  to  the  RSVP 
overview  data  screens  having  buttons,  pop-up  menus,  sliders  and  other  interface 
widgets  to  control  components 


RSVP  detailed  data  screens,  such  as  parameter  time  histories,  as  a  third 
health  monitoring  and  diagnosis  layer 

For  complete  results,  refer  to  the  “Manning  Functional  Analysis  Phase  III  Report”  [ref 
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6.2  Value  Analysis  using  the  Process  Analysis  Toolkit  for 
Affordability  (PATA)  -  IPPD  Analysis 

6.2.1  Introduction 

RSVP  tasked  James  Gregory  Associates  to  provide  a  Value  Analysis  RSVP  based  on  the 
IPPD  methodology.  This  analysis  was  conducted  using  test  data  collected  during  the 
demonstrations  of  the  system.  The  following  is  an  essential  summary  of  the  results.  For 
the  complete  Value  Analysis,  refer  to  the  “Value  Analysis  using  the  Process  Analysis 
Toolkit  for  Affordability  (PATA)  Report  on  the  Reduced  Ship's-crew  by  Virtual  Presence 
(RSVP)  ATD”  [ref  16]. 

Value  is  measured  using  two  fundamental  metrics,  desirability  and  risk.  It  is  assessed 
across  all  of  the  relevant  areas  (e.g.  performance,  cost,  and  schedule).  All  of  these  factors 
are  weighted  and  brought  simultaneously  into  the  assessment.  A  Value  Analysis  requires 
that  we  quantitatively  estimate  the  desirability  and  risk  of  one  or  more  technologies, 
processes,  or  design  concepts.  As  suggested  by  the  nature  of  the  desirability  curve,  it  is 
driven  by  the  customer’s  perspective.  Risk  is  measured  with  respect  to  customer 
thresholds.  The  process  itself  involves  building  up  various  estimates  using  underlying 
requirements  matrices  and  technology  worksheets.  The  result  is  a  Value  Scorecard  that 
contains  values  for  desirability  and  risk  that  are  traceable  back  to  the  original 
requirements,  thresholds,  and  desirability  curves. 


6.2.2  Scope 

Although  requirements  were  collected  for  the  production  system  to  be  fielded  in  CY 
2008,  we  only  focused  on  evaluating  the  requirements  as  defined  for  the  ATD 
Demonstration.  From  this  information  we  can  now  quantitatively  estimate  what  it  will 
take  to  transition  the  RSVP  technology  into  the  production  system. 

6.2.3  Objectives 

The  objectives  of  this  Value  Analysis  were  to: 

•  Evaluate  the  RSVP  ATD  Demonstration  system  in  terms  of  desirability  and 
risk. 

•  Identify  cost  drivers,  technology  shortfalls,  and  risk  areas. 

•  Use  the  results  of  the  value  analysis  to  build  the  business  case  for  transitioning 
the  RSVP  technology. 
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6.2.4  Approach 

The  RSVP  Integrated  Product  Team  (IPT)  applied  the  Science  and  Technology  (S&T) 
Integrated  Product  and  Process  Development  (IPPD)  Process  on  the  RSVP  ATD.  (See 
Figure  169.) 


Figure  169  S&T  IPPD  Process 


6.2.4.1  Requirements  Determination 

The  IPT  held  several  working  sessions  early  in  the  program  to  accomplish  the  first 
activity  of  the  IPPD  process— Determine  Requirements.  IPPD  begins  with  defining  user 
requirements.  The  essential  ingredient  in  any  system  design  is  the  identification  of 
complete,  precise,  unambiguous,  and  measurable  user  requirements,  and  that  such  an 
analysis  is  critical  if  the  system  design  is  to  provide  the  functionality  users  demand  and 
expect.  Given  a  controlled  set  of  user  requirements  to  identify  the  essential  system 
behavior  that  is  required,  one  can  design  an  optimal  system,  more  quickly,  and  at  less 
cost.  The  requirements  gathering  process  is  described  in  Section  2.2.  To  capture  and 
manage  the  requirements  for  the  RSVP  ATD,  the  IPT  used  the  Process  Analysis  Toolkit 
for  Affordability  (PAT A).  The  complete  IPPD  Requirements  are  found  in  Table  1. 
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6.2. 4.2  Desirability  Functions 

One  of  the  most  powerful  tools  used  in  the  S&T  IPPD  Process  is  the  desirability  function. 
One  of  the  important  benefits  of  thinking  about  requirements  in  terms  of  desirability  is 
that  it  promotes  discussion  with  the  customer  concerning  threshold  negotiation.  Thus,  it 
helps  the  team  reach  consensus  on  the  real  requirement — the  “must  have”  rather  than  the 
“nice  to  have.”  Figure  170  shows  an  example  RSVP  desirability  curve  from  the  PATA 
toolkit.  Notice  that  desirability  ranges  from  0  to  1  (or  0  to  100%)  and  is  a  function  of  the 
response  to  a  given  requirement.  In  this  case,  the  response  is  "Fire  Detection"  and  it  is 
measured  in  "Percentage  Detection  w/in  5  mins."  For  the  requirement  shown  in  Figure 
170,  the  RSVP  IPT  decided  that  they  would  be  extremely  pleased  with  a  100%  detection 
rate,  and  that  a  system  that  has  a  detection  rate  less  than  95%  is  undesirable. 

The  RSVP  IPT  constructed  desirability  curves  for  each  requirement.  We  used  these 
curves  and  the  associated  requirement  weights  to  calculate  the  desirability  of  the  RSVP 
Technology. 


Q  Desirability  Curve:  1  Ef  IEJ 


ATD  Demo:  Fire  Detection 


Percentage  Detection  w/in  5  mins 


Figure  170  Sample  RSVP  Desirability  Curve 
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6.2.4.3  Demonstration  and  Data  Collection 

The  RSVP  IPT  conducted  a  series  of  demonstrations  of  the  RSVP  technology.  Data  was 
collected  according  to  the  test  plan.  We  used  this  data  to  assess  the  RSVP  technology 
against  the  exit  criteria  in  terms  of  desirability  and  risk. 

6.2.4.4  Value  Analysis 

RSVP  performed  a  Value  Analysis  and  conducted  an  assessment  of  how  well  the  RSVP 
technology  had  met  the  requirements  for  the  ATD  Demo  customer. 

Value  analysis  involves  the  systematic  assessment  of  the  relative  value  of  a  technology  or 
design  concept.  The  assessment  is  performed  using  Value  Analysis  Worksheets.  For 
RSVP,  we  populated  seven  worksheets,  one  for  each  of  the  requirement  types  shown  in 
Figure  171,  except  "Schedule."  The  only  requirement  in  this  type  was  to  conduct  the 
RSVP  ATD  Demo  by  the  end  of  2001 .  This  requirement  was  met  and  was  therefore  not  a 
discriminator  in  the  analysis. 
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Figure  171  RSVP  Requirement  Types  and  Weights 

We  used  the  PATA  worksheets  to  capture  the  assessment  of  the  RSVP  technology 
against  the  ATD  Demo  requirements.  Once  the  data  was  entered  into  PATA,  the 
weighted  geometric  mean  was  used  to  compute  the  desirability  of  the  RSVP  technology. 
Desirability  was  first  computed  for  each  requirement,  then  for  each  requirement  type,  and 
finally  rolled  into  the  overall  desirability,  known  as  the  Customer  Satisfaction  Index 
(CSI).  Risk  was  measured  with  respect  to  the  ATD  Demo  thresholds.  For  each 
requirement  we  computed  the  probability  of  failing  to  meet  the  established  threshold.  We 
then  computed  the  overall  risk  of  failing  to  meet  at  least  one  of  the  thresholds  for  all  of 
the  requirements  of  a  particular  type. 

For  each  requirement,  an  expected  value  and  a  standard  deviation  were  captured.  The 
expected  value  and  standard  deviation  were  obtained  from  actual  RSVP  Demo  test  data 
and/or  expert  opinion.  Once  entered  into  the  worksheet,  the  PATA  calculated  the  risk  for 
each  requirement  based  on  the  threshold,  expected  value,  and  standard  deviation.  The 
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PATA  also  calculated  the  desirability  for  each  requirement  based  on  the  expected  value 
and  customer- defined  desirability  curve. 

The  information  in  the  worksheets  was  then  used  to  generate  a  Value  Scorecard.  The 
scorecard  contains  all  of  the  results  of  the  value  analysis  in  terms  of  the  RSVP 
technology  answered  the  ATD  Demo  requirements.  The  remainder  of  this  section 
presents  the  results  of  the  Value  Analysis. 

6.2.4.5  Technology  Worksheets 

The  seven  Technology  Worksheets  are  presented  and  discussed  in  the  following  sections. 
To  become  familiar  with  the  content  and  format  of  the  worksheet,  refer  to  Figure  172 
below.  Note  the  column  headings  for  the  worksheet.  The  "Requirement",  "How 
Measured",  "Objective",  Threshold",  and  "Weight"  columns  were  populated  early  in  the 
program  during  requirements  determination.  We  entered  "Expected  Value"  and  "Standard 
Deviation"  values  that  were  obtained  from  actual  RSVP  demonstration  test  data  and  /or 
expert  opinion.  The  individual  "Zeta"  and  "Desirability"  values  were  computed  by  the 
PATA  after  we  entered  the  expected  values  and  standard  deviations.  The  last  row  in  the 
worksheet  shows  the  total  Zeta  and  total  Desirability.  Zeta  and  Desirability  are  computed 
in  the  PATA  using  equations  1-3  shown  above. 

Note  that  desirability  ranges  from  0  to  1  with  values  closer  to  1  being  preferable.  Risk 
also  ranges  from  0  to  1  but  values  closer  to  0  are  preferable  since  we  view  risk  as  the 
probability  of  not  meeting  a  threshold  value. 

6.2.4.6  Cost  Worksheet 

Figure  172  shows  the  ATD  Demo  Cost  Worksheet.  The  total  Zeta  is  0.06494  and  the  total 
desirability  is  0.49.  This  Zeta  is  not  high,  but  the  desirability  is  somewhat  low.  By 
looking  at  the  individual  requirements  in  the  worksheet,  we  see  that  three  of  them  are 
contributing  to  the  low  desirability-Reduce  Manhours,  O&S  Costs  (Crew),  and  O&S 
Cost  of  RSVP.  Notice  that  these  three  are  weighted  as  the  most  important  cost 
requirements  and  their  individual  desirabilities  were  the  lowest  of  all  the  requirements. 
When  the  overall  desirability  for  cost  was  computed  using  the  weighted  geometric  mean, 
these  high  weights  coupled  with  the  low  desirabilities  caused  the  overall  desirability  to  go 
down.  It  should  be  noted  that  the  RSVP  technology  is  still  desirable  from  a  cost 
perspective  since  it  is  meeting  all  of  the  thresholds.  But  there  is  room  for  improvement 
and  the  analysis  points  to  these  three  requirements  as  place  to  look  to  make 
improvements. 
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Figure  172  Cost  Worksheet 


6.2.4.7  Environmental  Monitoring  (PerfEnv)  Worksheet 

The  Environmental  Monitoring  is  shown  in  Figure  173.  The  "Monitor  Humidity" 
requirement  was  removed  from  the  analysis  by  setting  its  weight  to  zero5  since  this  data 
was  not  collected  during  testing.  The  total  Zeta  was  .00196  and  the  total  Desirability  is 
.92.  The  only  individual  desirability  that  seems  low  is  on  the  "Fire  Detection" 
requirement  measured  in  "Time  to  Detection  (mins)."  The  lower  desirability  on  this 
requirement  is  due  to  the  shape  of  the  desirability  curve.  (See  Figure  174.)  Even  with  an 
expected  value  of  2  minutes  (which  is  very  close  to  the  objective  of  1  minute),  the  shape 
of  the  curve  determines  that  the  desirability  is  only  .54  —  leaving  room  for  improvement. 
It  is  interesting  to  observe  that  on  ten  out  of  the  fourteen  requirements,  the  RSVP 
technology  met  or  exceeded  the  objective  value.  Sensitivity  analysis  showed  that  the  total 
desirability  is  unchanged  if  all  weights  are  set  to  1 .0.  This  result  was  expected  since  the 
individual  desirabilities  on  most  requirements  were  large. 
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Figure  173  Environmental  Monitoring  Worksheet 


Figure  174  Fire  Detection  Desirability  Curve 
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6.2.4.8  Machinery  Monitoring  (PerfMach)  Worksheet 

Figure  175  shows  the  Machinery  Monitoring  Worksheet.  The  analysis  for  this  category 
closely  follows  that  of  the  Environmental  Monitoring.  The  total  Zeta  was  .00008  and  the 
total  Desirability  is  .93.  The  only  individual  desirability  that  seems  low  is  on  the 
"Determine  Operating  State"  requirement  measured  in  "Seconds."  One  reason  the 
desirability  is  somewhat  low  is  that  the  test  data  results  yielded  an  expected  value  of  10 
seconds.  (The  upper  threshold  is  60  seconds  and  the  objective  is  1  second.)  Collection 
and  analysis  of  high  bandwidth  data  at  equipment  delayed  response  time  for  on  demand 
data  requests  by  an  operator.  These  results  identify  the  need  for  two  data  collection 
schemes  1)  to  support  near  real  time  data  collection  for  presentation  to  the  operator  and 
2)  to  support  capturing  high  bandwidth  data  locally,  processing  it,  and  sending  the 
operator  messages  regarding  system  status.  The  lower  desirability  on  this  requirement  is 
also  due  to  the  shape  of  the  desirability  curve.  (See  Figure  176.)  The  shape  of  the  curve 
determines  that  the  desirability  is  only  .45-  leaving  room  for  improvement. 

Sensitivity  analysis  showed  that  the  total  desirability  is  unchanged  if  all  weights  are  set  to 
1.0.  This  result  was  expected  since  the  individual  desirabilities  on  most  requirements 
were  large. 
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Figure  175  Machinery  Monitoring  Worksheet 
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6.2.4.9  Personnel  Monitoring  (PerfPer)  Worksheet 

The  Personnel  Monitoring  Worksheet  is  shown  in  Figure  177,  As  the  results  show,  the 
RSVP  technology  performed  well  on  all  of  these  requirements  providing  a  total  Zeta  of 
0.1303  and  a  total  Desirability  of  0,97,  Again,  sensitivity  to  weights  was  investigated  and 
showed  that  the  total  desirability  is  unchanged  if  all  weights  are  set  to  1.0. 


313 


NSWCCD-TR-2003/02 


6.2.4.10  Structural  Monitoring  (PerfStruct)  Worksheet 

The  RSVP  technology  also  responded  well  to  all  requirements  in  the  Structural 
Monitoring  Worksheet  shown  in  Figure  178.  On  six  out  of  the  seven  requirements,  the 
RSVP  technology  met  or  exceeded  the  objective  value,  yielding  a  total  Zeta  of  only 
0.00001  and  a  total  Desirability  of  0.98.  Sensitivity  analysis  showed  that  the  total 
desirability  is  unchanged  if  all  weights  are  set  to  1.0. 

Notice  that  two  of  the  requirements— Monitor  Hatch  Closure  and  Monitor  Hatch  Open— 
were  not  considered  in  the  analysis. 
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Figure  178  Structural  Monitoring  Worksheet 
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6.2.4,11  System-Level  Monitoring  (PerfSys)Worksheet 

The  analysis  pointed  to  two  of  the  requirements  in  the  System- Level  Monitoring 
Worksheet  (Figure  179)  as  potential  areas  for  improvement  of  the  RSVP  Technology. 
The  Provide  System  Health  Status  requirement  had  a  Zeta  of  0.25265  and  a  Desirability 
of  0.51.  The  reason  for  the  somewhat  higher  Zeta  is  that  the  expected  value  for  the 
requirement  was  30  with  a  standard  deviation  of  45.  This  large  standard  deviation  caused 
the  higher  Zeta.  The  desirability  is  a  function  of  the  expected  value  and  the  desirability 
curve  (which  is  straight-lined). 

The  Wireless  requirement  was  measured  on  a  scale  of  1  to  5  with  5  indicating  the  RSVP 
technology  was  a  completely  wireless  solution.  Since  the  RSVP  ATD  Demo  had  some 
wired  technology,  the  rating  given  was  a  4.  Since  4  was  the  lower  threshold  for  the 
requirement,  the  resulting  Zeta  was  50  percent.  The  desirability  of  0.8  was  a  function  of 
the  desirability  curve  that  shows  the  customer  is  80  percent  satisfied  with  a  technology 
that  rates  a  4  on  the  1  to  5  scale. 
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The  overall  Zeta  was  thus  0.66578  due  mainly  to  the  Zeta  for  the  Wireless  requirement. 
The  overall  Desirability  was  0.81,  due  mainly  to  the  Provide  System  Health  Status 
requirement.  The  effect  of  setting  all  the  weights  to  1.0  was  an  increase  in  total 
desirability  to  0.84.  This  slight  increase  is  due  to  the  fact  that  4  of  the  5  requirements 
already  were  weighted  equally.  The  analysis  shows  then  that  the  Provide  System  Health 
Status  and  Wireless  requirements  need  more  attention. 

6.2.4.12  Power  Harvesting  Worksheet 

There  was  only  one  requirement  in  this  category.  As  the  worksheet  in  Figure  180  shows, 
the  RSVP  technology  achieved  some  power  harvesting  capability,  but  needs  considerable 
more  work  to  be  robust.  The  RSYP  technology  did  exceed  the  minimum  threshold  for  the 
requirement,  but  only  slightly,  thus  providing  a  high  risk  and  low  desirable  solution  for 
harvesting  power. 


Figure  180  Power  Harvesting  Worksheet 
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6.2.5  Value  Scorecard 

The  results  of  the  worksheet  analysis  are  summarized  in  the  Value  Scorecard  shown  in 
Table  44.  We  rolled  up  Desirability  and  Zeta  across  all  the  requirement  types,  yielding  a 
CSI  of  0.226  and  an  overall  Risk  of  0.845. 

The  low  CSI  is  traceable  to  the  following  requirements: 

Table  44  Value  Score  Card 


Requirement 

Requirement 

Type 

Desirability 

Reduce  Man-hours 

Cost 

0.40 

O&S  Cost  (Crew) 

Cost 

0.52 

O&S  Cost  of  RSVP 

Cost 

0.14 

Provide  System  Health  Status 

0.51 

Harvested  Power 

EHsggssiss® 

0.00007 

The  high  risk  is  traceable  to  requirements  in  Table  45 : 


Table  45  High  Risk  Requirements 


Requirement 

Requirement 

Type _ 

Zeta 

Provide  System  Health  Status 

m 

0.25265 

Wireless 

0.50020 

Harvested  Power 

Power  Harvesting 

0.41196 

The  requirements  listed  in  the  two  tables  above  (Table  44  and  Table  45)  are  the  drivers 
for  the  RSVP  technology  in  terms  of  risk  and  customer  satisfaction. 
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Figure  181  shows  the  results  of  the  Value  Scorecard  graphically  in  what  we  call  a  Radar 
Chart.  The  green  indicates  the  desirability  of  the  RSVP  technology  and  the  red  indicates 
the  risk  associated  with  the  RSVP  technology.  The  reader  should  not  interpret  the  green 
and  red  as  areas.  To  clarify,  the  Radar  Chart  shown  in  Figure  1 82  has  seven  spokes. 
Considering  only  the  Cost  spoke  for  the  moment,  we  assume  the  spoke  at  the  center  of 
the  circle  starts  at  zero  (0)  and  the  end  of  the  spoke  stops  at  one  (1).  Thus,  the  chart 
shows  that  the  desirability  of  the  RSVP  Technology  for  cost  is  approximately  0.5  (half 
way  out  the  spoke).  Referring  to  the  Value  Scorecard  in  Figure,  we  see  that  the  actual 
desirability  for  Cost  is  0.49.  The  risk  is  small  for  Cost  and  in  the  Radar  Chart  appears  to 
be  around  0.05.  Referring  to  the  Value  Scorecard  again,  we  see  that  the  Cost  risk  is 
0.06495.  To  complete  the  Radar  Chart,  we  plot  the  desirability  and  risk  on  each  of  the 
other  six  spokes.  We  connect  the  end  points  on  each  spoke  for  desirability  and  risk 
resulting  in  what  looks  like  an  area,  but  actually  is  not.  The  key  is  to  remember  to  look  at 
how  far  out  on  each  spoke  that  desirability  and  risk  reach. 
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Figure  182  RSVP  ATD  Demo  Radar  Chart 


6.2.6  Summary 

The  Value  Analysis  identified  the  requirements  of  the  program  that  are  driving  risk  and 
customer  satisfaction.  Specifically,  three  areas  that  need  more  work  are  Cost,  System- 
Level  Monitoring  and  Power  Harvesting.  Overall,  the  program  met  all  of  the  Exit  Criteria 
since  all  requirement  thresholds  were  met.  In  fact,  many  of  the  objectives  were  met  or 
exceeded. 
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7.0  Recommendations 

7.1  Technology 

7.1.1  Wireless 

There  is  a  tremendous  momentum  in  the  RF  market  to  use  a  Bluetooth  and  802.1  lb 
solution  in  a  given  wireless  system  architecture.  For  RSVP,  Bluetooth  and  802.1 1  are  not 
viable  solutions  for  a  truly  autonomous  (no  external  power)  sensor  network.  Batteries 
will  operate  for  a  limited  time  period.  If  system  architects  are  willing  to  make  the  tradeoff 
of  providing  external  power  and  increasing  total  system  cost  then  commercially  available 
radios  are  certainly  viable. 

7.1.2  Sensors 

There  were  several  efforts  in  both  academia  and  industry  that  are  relevant  to  the  RSVP 
Sensor  Cluster  but  one  particular  effort  illustrates  how,  in  the  future,  the  RSVP  Sensor 
Cluster  will  achieve  the  small  size  relative  to  today’s  Sensor  Cluster. 

7.1.2.1  MEMS  Spectrometer  for  Infrared  Gas  Analysis 

The  device  was  produced  by  a  team  from  the  Swiss  Federal  Institute  of  Technology 
Lausanne  -  Figure  183.  The  MEMS  infrared  spectrometer  can  be  selectively  tuned  for  gas 
analysis  and  quantification.  It  contains  a  tunable  optical  filter  of  porous  silicon  that 
allows  for  the  user  to  measure  the  infrared  absorption  of  a  gas  mixture  at  different 
wavelengths  serially  with  the  use  of  one  single  detector.  The  tunable  filter  is  typically  1 .0 
x  1.8  mm2  and  is  tilted  by  a  microactuator.  Selective  sensing  for  C02  and  CO  by  their 
absorption  bands  at  4.23  pm  and  4.65  pm  has  been  shown.  The  concept  is  illustrated 
below  and  is  then  followed  by  a  photograph  of  the  device  -  Figure  1 84.  Different  filters 
and  filter  combinations  can  be  added  to  the  device  to  cover  a  specific  or  broader  range  of 
chemical  detection  interests. 


Figure  183  MEMS  Spectrometer  Concept  Illustration 
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Figure  184  Photography  of  MEMS  Spectrometer 

7.1.3  Power  Harvesting 

7.1.3, 1  New  Thermoelectric  Material  For  Energy  Harvesting 

Hi-Z  Technology,  Inc.  has  been  developing  a  new  type  of  material  for  the  direct 
conversion  of  heat  to  electricity.  This  material  is  made  of  multiple  layers  of  two 
materials,  of  different  band  gaps.  Each  layer  is  about  100  thick  and  called  “quantum 
well”  thermoelectrics.  The  measured  thermoelectric  properties  of  this  material  indicate 
that  it  can  convert  heat  to  electricity  at  an  efficiency  that  is  roughly  four  times  that  of  the 
best  currently  available  bulk  thermoelectric  material.  One  of  the  physical  properties  that 
makes  quantum  wells  particularly  suitable  for  energy  harvesting  generators  is  its  high 
Seebeck  coefficient  (volts/  C)  which  means  that  higher  voltages  can  be  obtained  with  a 
very  low  temperature  difference. 


Figure  185  Schematic  of  P-N  Couple 

The  size  and  weight  of  the  energy  harvesting  generator  is  a  direct  function  of  the  thermal 
efficiency  of  the  conversion  because  the  size  of  the  generator  is  dictated  by  the  size  of  the 
air  side  heat  exchanger.  A  large  surface  area  is  required  to  transfer  the  energy  with 
minimal  temperature  loss  across  the  boundary  film.  A  factor  of  four  increase  in 
efficiency  provided  by  the  quantum  wells  will  result  in  a  factor  of  four  decrease  in  the  air 
side  heat  exchanger  size  and  weight. 
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7.1.3. 2  New  Thermoelectric  Wafer  Materials 

The  Research  Triangle  Institute  n  North  Carolina  has  reported  a  major  advance:  tiny 
“superlattice”  structures  that  appear  to  be  more  than  twice  as  efficient  as  previous 
thermoelectric  materials.  The  nano  films  consist  of  several  alternating  layers,  each  less 
than  five  nanometers  thick.  These  layers  block  the  travel  of  atomic  vibrations  that 
produce  heat  flow  but  still  let  the  electrons  flow  as  current. 


Figure  186  The  Research  Triangle  Institute  Thermoelectric  Wafer  Device 


7.2  MEMS-Based  Power  Generation 

The  MEMS-based  power  generation  community  is  primarily  focused  in 
microturbomachinery,  thermoelectrics  (TEs),  and  vibration  to  electric  systems. 

7.2.1. 1  Microturbomachinery 

The  microturbomachinery  effort  is  lead  by  Martin  Schmidt  of  MIT.  The  team  at  MIT  has 
demonstrated  several  of  the  individual  pieces  of  the  microturbine  but  still  have  several 
significant  “miracles”  to  overcome.  No  other  organizations  appear  to  be  playing  this  area. 

7.2. 1.2  Thermoelectrics 

Both  MIT  and  University  of  Michigan  presented  papers  on  thermoelectric  generators. 
Both  thermoelectric  generator  efforts  in  concept  use  a  micromachined  combustion 
chamber  for  heat  generator.  The  MIT  work  is  still  very  immature  and  is  demonstrating 
only  certain  key  principles  of  the  TE  side  of  the  power  generator.  The  MIT  team  stated 
they’ve  already  demonstrated  the  difficult  parts  of  the  micromachined  combustion 
chamber  half  of  the  problem.  The  University  of  Michigan  effort,  lead  by  Khalil  Najafi, 
presented  an  actual  thermoelectric  generator  consisting  of  MEMS  TE  device  coupled 
with  a  micromachined  combustion  chamber.  A  video  was  presented  that  showed  an 
operational  TE  system.  It  was  encouraging  to  see  a  more  integrated  systems  approach  to 
the  generator  rather  than  individual  pieces.  Both  teams  project  output  power  levels  to  be 
in  the  range  of  20-40|lW/thermocouple  at  450°C  (operating  temperature).  The  early 
results  from  the  University  of  Michigan  support  these  claims.  Figure  185  is  a  picture  of 
the  actual  University  of  Michigan  TE  generator. 
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Figure  185  University  of  Michigan-TE  Device 


Figure  186  TE  with  Combustion  Chamber 


7.2.1.3  Vibration  to  Electric  Generators 

Neil  N.  H.  Ching  (Chinese  University  of  Hong  Kong)  presented  a  device  that  was  very 
immature  in  nature  but  demonstrated  the  concept  of  vibration  to  electrical  conversion. 
Essentially  the  device  is  a  miniature  electromagnetic  generator.  A  small  magnetic  mass  is 
mounted  at  the  end  of  MEMS  spring  near  a  coil.  The  vibration  source  causes  the  magnet 
to  pass  by  the  coil  thus  inducing  a  voltage.  The  problem  with  this  type  of  power 
generation  is  that  the  device  needs  to  be  “tuned”  to  the  specific  vibration  source 
frequency  for  maximum  energy  transfer  and  if  the  device  not  sensing  that  particular 
frequency  then  the  device  is  essentially  non-operational.  There  are  a  few  companies  and 
universities  investigating  the  possibility  of  having  an  adaptive  approach  that  searches  or 
adapts  to  the  optimum  frequency  when  the  vibration  conditions  change.  The  output 
power  level  for  the  above  device  is  approximately  lOOjiW. 

7.2.1. 4  RSVP  Power  Scavenging  Efforts 

RSVP  has  both  a  TE  and  a  vibration  to  electric  generator.  The  RSVP  TE  device  is  from 
Hi-Z  Technology  (San  Diego,  CA)  and  the  vibration  to  electric  device  is  from  MJR 
Scientific  (Salt  Lake  City,  UT).  The  TE  device  is  not  MEMS-based  and  has  lower  output 
power  levels  due  to  the  fact  that  RSVP  is  operating  at  room  temperature  which  is  at  the 
low  end  of  the  efficiency  curve  for  the  material  used  in  TE  devices.  The  vibration  to 
electric  device  is  MEMS  based  and  has  similar  output  power  level  projections. 
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